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The invention relates to a chip card for carrying 
out transactions in which value data representing units 
of monetary value or other, non-monetary entitlements 
is transferred between the card holder and at least one 
transaction partner (service provider) or is presented 
to the service provider for verification of such 
entitlements. The chip card is characterized in that it 
comprises a memory in which the data required for 
carrying out the transactions is stored, and in that it 
has a device for loading the card with one or more card 
applications (VAS applications), which in each case 
permit transactions to be carried out between the 
cardholder and one or more service providers. 



O PIC 

Office db la paopaiixi 

INTKLLECTU&LLS DC CaKAOA 




C I P o 

Canadian Intellectual 
Profertt Office 



(i2)(i9)(CA) Demande-Application 



(72) ENGELHARDT, HOLGER, DE 

(72) MNZ, MICHAEL, DE 

(72) KISSINGER, STEFAN, DE 

(72) GOLLNER, MICHAEL, DE 

(72) KUCHELMEISTER, ANTON J , DE 

(72) SCHWIER, ANDREAS, DE 

(72) BURGER, ADELHEED, DE 

(72) RADNOTI, MICHAEL, DE 

(71) DEUTSCHE BANK AG, DE 

C7i) BB-DATA GESELLSCHAFT FUR INFORMATIONS- UND 

KOMMUNIKATIONSSYSTEME MBH, DE 
(51) IntCI. 6 G07F 7/10 
(30) 1996/12/23 (196 54 187.5) DE 
(30) 1997/04/29 (197 18 1 15.5) DE 

(54) CARTE A PUCE ET SON PRO CEDE D* UTILISATION 
(54) CHIP CARD AND METHOD FOR ITS USE 



(2i)(M) 2,275,931 

(86) 1997/12/19 

(87) 1998/07/02 



E3 



39ft fir wfbm 



"1 ! 
M L. 



VAS-Contenitr 



Off 0H OTHER 
CARD APPLICATION 



GLOBAL DATA 
OF THE V AS 
C0KTAJNER 




N0N-PR0PRIBARY 0 ATA 
OF THE VA5 PR0VBER5 



PROPRIETARY 
DATA OF THE 
VASPR0VCERS 



Industrie Canada Industry Canada 



O PIC 



Office de la propriety 

INTELLECTS BILE OC CaNADA 




CI PO 

Canadian Intellectual 
Property Oppice 



(2i>(Ai) 2,275,931 

(86) 1997/12/19 

(87) 1998/07/02 



(57) Carte a puce servant a cflcctucr des transactions pour 
lesquelles des donnees de valeur representant des unites 
de valeur monetaire ou d'autres titres non-monetaires 
sont transmises entre le titulaire de la carte et au mo ins 
un partenaire de transaction (foumisseur de service), ou 
sont presentees au foumisseur de service pour 
verification des titres. La carte d puce seion rinvention 
est caracterisee en ce qu'elle comprend une memo ire 
dans la que lie sont memorisees les donnees requises pour 
effectuer les transactions, et en ce qu'elle presente en 
outre un disposilifpour le chargemenl d'unc ou plusieurs 
applications de cartes (applications VAS) sur la carte, 
permettant d 'effectuer des transactions entre le titulaire 
de la carte et un ou plusieurs fournisseurs de service. 



(57) The invention relates to a chip card for carrying out 
transactions in which value data representing units of 
monetary value or other, non -monetary entitlements is 
transferred between the card holder and at least one 
transaction partner (service provider) or is presented to 
the service provider for verification of such entitlements. 
The chip card is characterized in that it comprises a 
memory in which the data required for carrying out the 
transactions is stored, and in that it has a device for 
loading the card with one or more card applications 
(VAS applications), which in each case permit 
transactions to be carried out between the cardholder and 
one or more service providers. 
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(54) Title: CHIP CARD AND METHOD FOR ITS USE 

(54) Bezeichnung: CHIPKARTE UND VERFAHREN ZUR VERWENDUNG DER CHIPKARTE 
(57) Abstract 

The invention relates to a chip card for carrying out 
transactions In which value data representing units of mone- 
tary value or other, non-monetary entitlements is transferred 
between the card holder and at least one transaction partner 
(service provider) or is presented to the service provider for 
verification of such entitlements. The chip card Is character- 
ized in that it comprises a memory in which the data required 
for carrying out the transactions is stored, and in that it has a 
device for loading the card with one or more card applications 
(VAS applications), which in each case permit transactions to 
be carried out between the cardholder and one or more service 
providers. 
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Chipkarte, die rut Durchfuhrung von Transaktionen di- 
em, be! denen geldwerte Einheiten oder andere nJcht-monetarc 
Anspruche ieprasentiereode Wertdaten zwischen dem 
Karteninhaber und mindestens einem TmnsakUonspartner 
(Service-Provider) Obertragen Oder dem Service-Provider zur 
Verifiziening dcr Ansprttche vorgewiesen werden, wobei die 
Chipkarte emen Speicber umfaBt, in dem zur Durchrunrung der 
Transaktionen erforoeriicbe Oaten abgespeJchert werden, und 
die Chipkarte fomer tblgendes aufweist' cine Einrichtung zum 

Laden von einer Oder mehreren Kartenanwendungcn (VAS-Applikationen) auf die Kane, die jeweiU die DurchfQhrung von Transaktionen 
zwischen dem Kartenmhaber und einem oder mehreren Service-Provider erraoglichen. 
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Chip card and Process for the Use of the Chip Card 

The invention relates to a chip card, a terminal for use with a chip card and a 
process for using the chip card as well as a chip card system. 

Micro-processor chip cards having a payment function, e.g. electronic purse, ec- 
cash, credit function etc.. are already in use and, depending on their nature, 
preconditions are laid down by organisations, e.g. ZKA (Zentraler KreditausschuB), 
VISA or EMV (Europay Mastercard VISA), so that they can be used as a means of 
payment ("cash substitute). By way of example the following may be mentioned 
here: . " - . . ..... - \ 

ZKA, Zentraler KreditausschuB, "interaction specification for the ec-card with 
chip", 27.10.1995; 

Europay International, "Integrated Circuit Card, Specification of Payment 
Systems, EMV96", V3.0, 30-Jun-1 996; 

ISO/IEC 7816-4, "Information technology - Identification cards - Integrated. 
circuit(s) cards with contacts, Part 4: Interindustry commands for 
interchange", 01-09-1995; 

prEN 1546-1, "Identification card systems • Inter-sector electronic purse, Part 
1 : Definitions, concepts and structures", 1 5.03.1 995; 

prEN 1546-2, "Identification card systems - Inter-sector electronic purse, Part 
2: Security architecture", 03.07.1995; 

prEn 1546-3, "Identification card systems - Inter-sector electronic purse, Part 
3: Data elements and interchanges", 09.12.1994. 

An up-to-date survey of chip cards may be found in: 

Stefan Schutt, Bert Kohlgraf: "Chipkarten, Technische Merkmale, Normung, 
Einsatzgebiete", ("Chip cards, Technical Characteristics, Standards, Fields of 
Employment 1 '), R. Oldenbourg Verlag. MunichA/ienna, 1996. ISBN 3-486- 
23738-1. 
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Conventional chip cards are. as a rule, usable only for a particular purpose, for 
example as electronic money purse or as an electronic identification means. 
However, the applications applied to these chip cards, as a rule, are static, i.e. they 
are applied during the manufacture of the chip card and are preserved unchanged 
throughout the life cycle of the card. 

Conventional chip cards are limited both with regard to their variability as well as 
with regard to their functionality. In particular, conventional chip cards are fixed 
according to their manufacturing process with regard to their functionality and can 
no longer be changed. 

It is accordingly an object of the present invention to provide a chip card, the 
functionality of which is variable. 

A further object of the invention resides in providing a chip card for which the 
number and nature of the application performable by the chip card or the 
applications and transactions may still be variable, even after the manufacturing 
process. It should be possible to load onto these chip cards additional applications, it 
should be possible to delete applications from the chip card and the individual 
applications are to be defined independently from one another in data and security- 
technological respects and to proceed independently from one another. 

The chip card should, for example, comply with the data and security-technological 
conditions according to ISO 7816; the individual applications of the card should, 
however, be independent in particular from the card platform itself. 

It is a further object of the invention to provide a chip card with which the user 
himself may determine or combine or change the number and nature of the 
applications available in his card. 

It is furthermore an object of the present invention to provide a chip card by means 
of which both intraservices (i.e. closed-loop applications within the sense that no 
bookings and service transfers involving external . partners have to take place) as 
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well as interservices (i.e. applications with additional external relations involving 
external partners) are possible and can be performed. 

According to one aspect of the invention an apparatus is provided by means of 
which one or more card applications can be loaded onto the card by each of which 
the performance of transactions between the cardholder and one or more service 
providers is made possible. 

By such loading the chip card is so configured that it is provided with a new 
functionality, i.e. can perform an application which was previously not open to it. The 
loaded data cause applications being defined and realised in conjunction with the 
basic functionalities of the card such as the operating system which previously were 
not provided on the card. As a result the functionality of the card is extended by 
such loading of an application by this particular application. 

According to an embodiment of the invention a data structure ( DF_VAS) is provided 
on the chip card according to the invention which in turn is subdivided into a partial 
structure and a definition data set, the data structure being distinctly identified by 
means of a coding identifying it and is thus independent of the card platform. So- 
called applications can now be loaded into the partial structure, i.e. functionalities or 
applications of the chip card. As a result it becomes possible by loading a particular 
application of the chip card, to perform transactions between the cardholder and a 
service provider specific for this application. A definition data set within the data 
structure contains information concerning the nature and/or the structure of the 
applications loaded into the partial structure. At least the definition data set, 
preferably, however, the entire data structure are secured by means of at least one 
system key against modifications and are modifiable only by using this key. Instead 
of a system key other security mechanisms as well or security means can be 
conceived by means of which securing against modifications may be provided, for 
example by a personal identity number (PIN) or other means serving such security. 

By the above structure it is possible to load into the partial structure a variety of 
applications and also to delete these once again from the partial structure whereby 
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the card is rendered variable with regard to its functionalities or the applications 
which may be performed therewith. Loading and deleting of applications proceeds 
by writing application specific data and keys into the provided partial structure. By 
the provision of the system key and the data structure coding, the data structure 
permitting the multi-functionality is rendered independent from the card platform as 
such and also with respect to its security architecture self-supportingly from and 
independently of the card platform. 

Dependening on the applications loaded into the partial structure, it is then possible 
to perform by means of the card transactions between the cardholder and service 
providers which are dependent on the loaded applications,. 

Preferably, the chip card further comprises a transfer storage region into which the 
data to be exchanged during the performance of transactions may be written or from 
which they can be read. For reasons that for the reading of data from the transfer 
storage region terminal-specific keys are provided, the individual accesses are 
rendered independent from one another from a security point of view. 

The individual partial structures or applications- provided for in the card are 
preferably mutually independent and each allotted to a specific service provider. 
They represent, so to say, the data for performing a specific application, proprietary 
or specific to this service provider. Depending on the application type and depending 
on the service provider they, therefore, contain different information, for example 
data representing a specific value (bonus points, account balance etc.). information 
data concerning the application, information data concerning the service provider 
etc. Preferably, however, they in particular contain keys which are specific for the 
application, by means of which access to the data of the partial structure is rendered 
possible in a manner which security-technical^ is independent from other partial 
structures. Loading or generating the partial structure or application itself on the 
other hand, is safeguarded by at least one superimposed system key. 
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Preferably, prior to the performance of a transaction, a mutual authentication 
between the chip card and a terminal takes place, an application, respectively partial 
structure specific authentication key being provided for that purpose. 

In order to perform transactions, data are then written into a partial structure 
reserved for the particular VAS-application or are read therefrom or are performed 
by way of the transfer storage region. In the first instance, application specific keys 
are used. In the last mentioned case, an application specific and preferably also 
terminal specific key is used which is, for example, generated by means of a key 
generating key provided on the card and from application specific data. The data 
thus written into the transfer storage may then be withdrawn by the service provider 
by way of the terminal, which preferably takes place by marking as invalidated the 
data stored in the transfer storage. If this involves a service provider who is not 
specific for the application being written, this involves the performance of a so-called 
interservice, i.e. monetary data are exchanged for the benefit of or the cost of the 
cardholder between different service providers. 

Furthermore, for additional security, a PIN or a password is provided for verification 
of the right to perform a transaction procedure. 

The variable structure of the card permits the accommodation on the card at 
different times of a variety of applications in a variety of numbers. 

The veracity of data withdrawn from the transfer storage is preferably secured by the 
use of a signature key or by using a digital signature or at least a key. However, in 
this context it is particularly advantageous if the data withdrawn remain in the 
transfer storage and are merely labeled as having been withdrawn by way of the 
card. In this manner it is still possible to obtain information concerning the 
transaction performed even after the transaction has taken place. In this manner 
and by means of the securing of the withdrawal it becomes provable that a 
transaction has only been performed once. 
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It is furthermore particularly advantageous if the data written into the transfer 
storage are encoded with an expiry date after which they lose their value. Thus, it 
becomes possible to perform applications which, for example, involve the making 
available of a ticket valid only for a specific period. 

By means of a transaction counter which is preferably provided, transaction dates, 
respectively the value data with respect to their associated transaction can be 
positively determined and identified. 

* 

In an advantageous embodiment, the chip card according to the invention therefore 

comprises a hierarchical database concept which at its individual planes is secured © 

by means of different keys against modifications, which at the level of the 

applications regarding the application stored in the database is variable, each 

individual application being secured in relation to the remainder by its own specific 

key and being independent of the remainder, and the overall structure being 

secured by at least one system key and by coding identifying the structure and being 

independent of the card platform itself. The concept of the transfer storage permits 

the exchange of data both between cardholder and service provider as well as 

between different service providers as such. Also, reading from and writing into the 

transfer storage is secured by keys, these being likewise card and application 

specific, additionally also, terminal specific. An authentication performed prior to 

each transaction as well as optionally a PIN or a password additionally increase the 

security of the chip card according to the invention. C ) 

In patent claims 21 to 30 a terminal for use with the chip card according to the 
invention is defined. This terminal serves for loading or deleting applications, for 
performing transactions, for viewing of data as well as for performing further 
functions in conjunction with the respective applications and transactions. A process 
for performing transactions between the cardholder and service provider is defined 
in claims 31 to 33. the loading of data onto a chip card according to the invention is 
defined in claim 34 and 35, and claim 36 defines an overall system comprising a 
chip card and terminal. 
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In the following the present invention is further described by way of a preferred 
example, with reference to the accompanying drawings. There is shown in: 

Fig. 1 diagrammatically, the chip card according to the invention, 

Fig. 2 A schematic representation of the overall system of the components of 
the invention, 

Fig. 3 the data flow in the overall system, 

Fig. 4 the possible application classes and operations through a transaction 
model in schematic illustration, 

Fig. 5 a schematic illustration of the security architecture of the chip card 
according to the invention, 

Fig. 6 the data structure of a general implementation class of the VAS- 
container, 

Fig. 7 a variety of implementation classes of the VAS-container according to a 
working example of the present invention, 

Fig. 8 the database structure of the VAS-container according to a working 
example of the present invention, 

Fig. 9 schematically, the database structure of the implementation class DF_PT, 

Fig. 10 schematically, the database structure of the implementation class 
DF_AD. 

Before the invention is further described, a number of terms used will be defined in 
what follows: 
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VAS: Value Added Services 

VAS-card: The VAS-card is a chip card by means of which it is possible to 
participate in the Value Added Services. The VAS-card besides other applications 
such as e.g. payment applications (i.e. electronic money purses) contains the VAS- 
container. 

VAS-container. The VAS-container comprises data structures, access conditions, 
keys and (supplementary) commands for administering VAS-applications and for the 
availability of the functionality of the VAS-applications. 

VAS-application: VAS-applications contain VAS data. Access to the VAS data is 
controlled by way of the VAS-application. A VAS-provider operates in the VAS- 
container one or more VAS-applications. The utilisation of the VAS-application is 
defined by the application, reading and processing of VAS data. A VAS-application 
may take the form either of an intra- or an interservice. 

VAS-provider. The VAS-provider is responsible for his VAS-application which he 
develops according to basic conditions of the system operator and according to his 
own discretion and thereafter makes available for use to the cardholder by way of 
the system operator and the terminals. The VAS-applications are to be loaded into 
the VAS-container of the VAS-card prior to it being possible to participate therein. 

tntraservice: Intraservice is a kind of VAS-application utilised under the exclusive 
management of the respective VAS-provider. Intraservice applications are closed- 
loop applications, meaning, that no accounting or performance transfers with 
external partners take place. A VAS-application may be either of an intra- or an 
interservice nature. 

Interservices. Inter service applications are intra service applications which by way 
of additional external connections interact with external partners. A VAS-application 
may be either intra or inter service by nature. 
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SO, system operator: The system operator offers to the VAS-providers and the 
cardholders the VAS system for use by them. 

Issuer: The issuer or card issuer brings the VAS-cards, including VAS-containers f 
into circulation. 

CH t cardholder: The cardholder or card proprietor is the person who owns and 
employs the card (in this case: VAS-card) in order to participate in the Value Added 
Services. This person is not necessarily the actual owner of the card. 

Service terminal: The service terminal is set up by the system operator for VAS- 
applications. At the service terminal the cardholder may administer the VAS- 
applications on his VAS-card (loading, viewing, deleting and transfer of VAS- 
applications). 

Dealer terminal: The dealer terminal possesses payment functions and in addition 
offers VAS functionality. This is where the cardholder applies his VAS-card in order, 
on the one hand, to make payment and, on the other hand, to participate in the 
benefits of VAS. 

AID: (Application Identifier), name of applications no longer than 16 bytes for the 
unambiguous differentiation of applications and the application selection from 
outside without knowledge of the database structure of a card. The AID consists of a 
Registered Application Provider ID (RID), 5 bytes long, and optionally a Proprietary 
Application Identifier Registration (PIX) f not longer than 1 1 bytes. 

DF: Directory File according to ISO 7816 

EF: Elementary File according to ISO 7816 

Valid VAS-container: VAS-container which has the ability to authenticate itself in 
relation to the outside world. 
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KID: (Key Identifier) number of a key within an elementary file containing keys 
R&R: Rules and Regulations 

p: Maximum number of objects of the implementation class DF_PT 
a: Maximum number of objects of the implementation class DF_AD 
nr om : Maximum total number of objects: nr DIR = p + a 
The number of records in EF_DIR is nr 01R 

TRANSFER 

: Number of records of the EF TRANSFER 

Fig. 1 shows schematically the structure of the chip card according to the invention. 
In addition to the static, immutable data applied during the manufacturing process 
such as the master file MF and the (optionally provided) money purse function 
DF_purse, there is further provided on the card in accordance with the invention an 
index or a data structure or database structure DF_VAS. This serves for 
accommodating additional functionalities, so-called Value Added Services, VAS. On 
the basis of these additional functionalities which represent applications which even 
at a later instance, that is to say after the card has been manufactured, may be 
loaded onto the card, the card in respect of Its functionalities and the transactions 
which may be performed therewith, is flexible and variable. The so-called VAS- 
container (DFJ/AS) provided on the chip card in accordance with the invention, 
permits the variability and flexibility of the chip card in respect of its functions and 
besides, releases the applications accommodated on the chip card security- 
technologically from the card platform, rendering these independent of the card 
platform and permitting these even to be transferred to another card. 

The new additional functionalities according to the invention (Value Added Services, 
VAS) are realised by way of microprocessor chip cards. The conversion of these 
additional functionalities is brought about by the VAS-container. The VAS-container 
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on the microprocessor chip card constitutes the platform for accommodating the 
VAS-applications. The VAS-appiications are the respective realisations of specific 
additional functionalities. 

In the case of the electronic money purse payment by means of the card (payment 
function) and the utilisation of a VAS-application (additional functionality) is 
performed by way of separate mechanisms; in the hands of the card user or 
cardholder these may. however, appear as a single procedure. 

The microprocessor chip card is extended by the VAS-container which can 
accommodate a variety of independent applications. It makes available functions for 
the application, deletion and transfer of such applications; these may only be used 
by the authorised system operator. The VAS-container is independent of other 
system components on the microprocessor chip from a data and security- 
technological point of view. The VAS-container is totally self-defined and functional 
on its own. An independent security architecture is defined for it, so that VAS- 
applications utilise independent security functions. The security architecture utilises 
card specific keys which are not manufacturer specific and which are independent of 
the identification features of the card platform. 

The VAS-container also uses mechanisms for deriving terminal specific keys. By 
means of these the VAS-container itself may actively check the authenticity of 
terminals, respectively of the data generated by them. 

In the VAS-container the VAS-applications are filed which by way of mechanisms of 
the VAS-container render data available, thereby bringing about the control of the 
associated interface points. The VAS-container permits and controls also the secure 
interchange of data for interservices between partners. The VAS-container actively 
takes care of the control, i.e. the authenticity and the uniqueness of the transferred 
data values. 

An advantage of the VAS-container as compared with other approaches to multi- 
application cards is that this concept is independent of a specific card platform. It 
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offers., a security architecture which is independent of platform specific security 
mechanisms (such as keys, identification data. PIN, signature procedures). 

A further advantage of the concept of a VAS-container is that the number of different 
applications on the card is not rigidly predetermined by limitations and preconditions 
at the time of card manufacture or card issue; the current loading of the card with 
applications may be freely selected by the card user and is restricted only by the 
storage capacity available on the specific card. The number of VAS-applications 
loaded onto a card at any given time depends on the actual use of the card. The 
card user individually assembles the VAS-applications on his card; this also involves 
modifying the combination at a subsequent instance. The VAS-container permits a 
multifunctional card in which the card functionality during the life cycle of the card 
may be assembled and used in a variable manner with regard to number and nature 
of applications. It is thus also possible to load onto and use with a single card 
applications for which in the past individual special cards were needed. VAS- 
applications may also be transferred to other cards. Accordingly, VAS-applications 
may survive beyond the life cycle of a card; they accompany the card user during 
the life cycle of such applications. 

The microprocessor chip card with additional services is a suitable medium for the 
distribution and marketing of services for which access must be had to protected 
data. This microprocessor chip card may be used as a means of payment, a 
counting unit and for value storage. It may be provided with additional services and 
be used for the control thereof in accordance with client wishes by the client himself 
and after the card has been issued, in a flexible manner. It also actively controls the 
authenticity of participating terminals and secures the uniqueness and authenticity of 
transferred data. 

Fig. 2 shows a system diagram. It illustrates the system components. A system 
operator makes the system available. VAS-applications may be loaded, deleted and 
transferred at the service terminals (ST); further operations are: selection, viewing, 
interpretation etc. of VAS-applications. 
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The providers of VAS-applications, the so-called VAS-providers design their own 
VAS-applications according to the basic conditions of the system operator and, as 
far as possible, according to their own wishes. The corresponding terminal 
programmes may subsequently be checked for authenticity by closure with a digital 
signature. 

Fig. 3 illustrates the data flow in the system. 

The VAS-applications are made available for use at the terminals of the card users 
by the system operator. VAS-applications must be loaded into the VAS-container of 
the chip card according to the invention, prior to participation therein being possible. 

At the dealer terminal (HT) the VAS-applications present on the card are utilised by 
the application or deleting of VAS-data. 

In order to provide the microprocessor chip card with VAS-functionality, the VAS- 
container is applied onto the card in addition to existing applications (e.g. payment 
applications such as the electronic money purse). 

The VAS-container uses functions which permit entering, deleting and transferring of 
VAS-applications. These administrative functions are used exclusively by the system 
operator and are secured in the card against foreign use. The VAS-container 
includes a transfer data storage by means of which exchange of data between VAS- 
applications is brought about. 

Two commands, TRANSFER and TAKE are employed for controlling the transfer 
storage. The command TRANSFER generates an entry in the transfer storage with 
data specific for the respective application. Besides the utility data these furthermore 
include entries such as date, expiry date and identification data needed for the 
control of the processing. By means of the command TAKE objects are withdrawn 
from the transfer storage and marked as having been withdrawn. Depending on the 
specific application, the objects are then marked either as remaining valid or as 
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being invalidated. Transferred data are checked by the VAS-container in respect of 
authenticity and uniqueness. 

VAS-applications utilise VAS-data for'" making available and controlling the 
applications. Access to the VAS-data is controlled by the VAS-app!ication utilising 
mechanisms which are made available to all applications in the VAS-container. A 
VAS-provider operates in the VAS-container one or more VAS-applications. The use 
of the VAS-application is defined by the entering, reading and processing of VAS- 
data. 

The VAS-container supports interservices. Interservices require access, to common 
data, transfer of service demands and the invoicing of sen/ices between different 
partners. 

In the following the services and applications made possible by the chip card 
according to the invention are to be listed with reference to examples. 

In each case the description relates to the realisation and function according to the 
present state of the art. In future the function is to be mimicked by one or more VAS- 
applications. 

Firstly intraservices are to be presented. 
Example A: Customer club 

A department store operates a customer club. The customer becomes a club 
member and in conformity with this status receives specific club services which are 
not available to non-members. Nowadays a club member identifies himself in the 
club environment by a club membership document. The club membership document 
is prepared when joining, is non-transferable and, as a rule, has a limited term. No 
specific transactions are performed by way of the club membership card, i.e. there is 
no linkage with the customer turnover. In this manner the club membership card is 
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separated from bonus programmes in which a connection exists between status and 
turnover. 

Wholesaler membership card, senator card, book-club card 

The club membership is to be evidenced by an application in the VAS- 
container. 

Example B: Bonus system 

A customer is credited for each transaction by a bonus claim. The bonus claim, is 
cumulated and may at the time determined by the customer be exchanged for a 
monetary benefit. The bonus claim is valid for a defined period and may be 
administered anonymously or person-related. The bonus claim arises from turnover 
or user frequency. 

Analogue: Points status of Miles & More 

Object: The points account is to be administered by an application in the VAS- 
container. 

Example C: Discount 

The customer receives a scheduled turnover discount. The discount is allowed for 
each individual transaction. The card administers no turnover history. Each 
transaction stands alone. 

Object: The discount entitlement is to be authenticated by a VAS-application. 
Example D: Identity document function 

A person is enabled by features in the card to prove to third parties his entitlement to 
predetermined services. The association of the person with the identity document 



Analogue: 
Object: 
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must be authenticated for each transaction (photograph. PIN, biometrics). The 
genuineness of the identity document is used as a security feature. 

Analogue: Internet access, access to homebanking. telephone card 
Object: The authorisation is to be proven by a VAS-application. 
. Example E: Value units 

Value units are purchased and consumed by single or multiple uses. By each 
transaction the value is reduced by one or more units. The user entitlement is 
transferable and may be subject to limitations as to usage. 

Analogue: Single travel ticket, multiple travel ticket, subscriber concert ticket, 
squash 1 0-points ticket, cinema ticket, telephone units 

Object: The transaction is to be rationalised by a VAS-application. 

Example F: User invoicing 

The use of a service is registered in terms of time, frequency or quantity and is 
invoiced according to a tariff. The extent to which the service will be called upon is 
not known in advance. 

Analogue: Meals voucher, short-term parking ticket 

Object: By a VAS-application invoicing according to tariff is to be permitted. 

The invoicing data applicable to each specific instance, are to be 
stored in the VAS-container. 

Example G: Data record (mobile database) 
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This application permits the transfer of data of the cardholder to the VAS-provider. 
Transactions are thereby automated which at present must still proceed manually. 
No monetary transfer can be derived from these data. 

Analogue: Completion of numbers pool vouchers, shopping lists, cash receipts, 
telephone registers 

Object: A VAS-provider is to derive the data from the card so as to be able to 
directly provide the required service (e.g. provide a telephone 
connection, compile desired purchases, electronic completion and 
recording of numbers poo! ticket).. The data may be stored in the card 
either short-term or long-term. 

These examples of intraservices are now to be followed by some examples for 
interservices. 

An interservice arises whenever a plurality of VAS-providers participate in a service. 
This is invariably connected with data leaving the environment of one VAS-provider. 
To date this is performed by paper records. 

Example A: Travel cost refund 

A department store refunds to a customer the travel ticket of a public transport 
enterprise for travelling to the department store. The customer must produce to the 
department store the single travel ticket. The department store notes on the ticket 
that it has been refunded. It may be that the department store in turn receives from 
the transport enterprise part of the refund to the customer. 

Object: The refund procedure is to be performed electronically. 
Example B: Travel voucher 
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A department store refunds to the customer when making a purchase the cost for a 
homeward trip by issuing a voucher. The customer at the ticket office receives a 
ticket from the public transport enterprise or pays a lower price for the ticket. The 
transport enterprise invoices the voucher to the department store. 

Object: Mimicking of the mechanisms by VAS-applications involving electronic 
accounting between the trade and the public transport enterprise. 

Example C: Customer parking 

A department store refunds to the customer part of the parking fees when using a 
particular parking garage. The parking garage is operated by an independent 
enterprise and receives from the department store a monetary payment for each 
customer credit. 

Object: Mimicking the mechanisms by VAS-applications involving electronic 
accounting between the trade and the parking garage. 

Example D: Multilateral bonus programme 

A group of trading enterprises and service providers agrees on a joint bonus 
programme. 

Object: Each partner may credit or debit bonus points against a common 
account on the card. Accounting for the services between the partners 
proceeds by the underlying system. 

Example E: Recognition of bonus points between service providers. 

Each service provider operates its own bonus programme but has entered into 
agreements with others to recognise collected points. Known examples are 
agreements between car rentals and airways for the collection of "miles". 



is 



CA 02275931 1999-06-22 



Object: Supporting the transfer of bonus points via the card. Each VAS- 
provider is initially to collect his points for himsetf without interference 
by somebody else. Certain mechanisms are to be made available for 
the transfer. 

Example F: Night taxi 

By purchasing a travel ticket of the public transport corporation, the right to travel in 
a collective taxi (e.g. after 22h00) is simultaneously acquired. For accounting 
purposes, the taxi enterprise must prove that a travel ticket had been presented. 
The use of the taxi is noted on the ticket in order to avoid abuse. 

Object: The VAS-application is to permit the utilisation, control and accounting 
of this service. 

In the following the structuring of the chip card according to the invention will be 
further described. 

More particularly, the microprocessor chip card with VAS-functionality contains the 
VAS-container. 

The VAS-container constitutes an application in its own right and exists either alone 
or even in parallel to other applications on the basic card platform. The VAS- 
container is completely self-defined and functional on its own. It can be operated 
without the payment function usually present on the same card. In particular, an 
independent security architecture is defined for the VAS-container so that VAS- 
applications can use independent security functions. 

Part of the Value Added Services are transactions by the client performed at 
terminals of the VAS-providers. The VAS-provider has an interest in monitoring 
these transactions, be it for the purpose of system control or for the collection of 
statistic and other data. In order to optimise and unify the data structures in the card, 
the use of application specific identifications is not recommended and the use of an 
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unambiguous VAS-container ID applicable to the whole system is advised. This 
number can be used by the VAS-provider for practising the abovementioned 
functions and it releases him from the burden of administering his own numbering 
systems. 

The security architecture of the VAS-container uses this system wide unambiguous 
ID in order to derive card specific keys. The use of the card specific number would 
be possible in principle but is preferably not used because, should the VAS- 
container be implemented on different platforms, these may in certain instances use 
clashing numbering systems. 

The VAS-container ID is issued by the system operator and entered by the card 
issuer when generating the VAS-container. It is destroyed on deleting the VAS- 
container and thereby removed from the system. A VAS-container is deemed as 
having been deleted if it contains no VAS-applications and if the VAS-container ID 
has been removed. 

During a total transfer of the VAS-container from an old into a new card, the VAS- 
container ID is transferred jointly with the VAS-applications. This transfer 
corresponds to a removal of the VAS-container from the old into the new card. After 
this procedure the old card no longer contains a VAS-container. The VAS-container 
present in the new card is overwritten during this operation and thereby deleted. 
Since the VAS-container ID is transferred from the old to the new card, no 
transformation of the reference numbers is necessary in the basic systems of the 
VAS-providers. 



Individual VAS-applications can be transferred between two different VAS- 
containers only under the control of the prevailing VAS-provider. During this function 
the association between VAS-container ID and VAS-application is changed which 
may have to be recorded in the basic system of the VAS-provider. 

The VAS-container contains no personalised features. VAS-applications may 
contain personalised data, the extent thereof should, however, be kept to a 
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minimum for data protection reasons and for improved memory utilisation. VAS- 
applications should, if necessary, store person-related data in the basic system and 
create the association with the card by way of the VAS-container ID. 

The support of interservices constitutes an important feature of the VAS-container. 
Interservices require access to common data, transfer of services claims and the 
accounting of services between different partners. The VAS-container must make 
these possible and, in spite of this, warrant the security of the applications in the 
intraservice. 

So-called intraservice VAS-applications are applications which are operated under 
the exclusive control of the VAS-provider. The VAS-provider defines the security of 
its application independently from any external entity. No external party can modify 
VAS-data without proliferation of the key. 

For the efficient performance of interservices the partners must be able to access 
common data. The joint access to the data is realised by way of multiple-step 
security mechanisms. 

The first step of the joint access proceeds exclusively by way of public transfer 
fields. VAS-providers may interchange data by way of these fields without mutual 
knowledge of the applications and keys being necessary. The terminals only require 
suitable keys for the entering of data into the transfer fields but not for reading. 
Anybody may read without limitation. The data interchange may proceed in both 
directions between VAS-provider and partner if each has his key available for data 
entering. The transfer data may be generated from an intraservice VAS-application 
of the VAS-provider or, vice versa, the VAS-provider may enter data from the 
transfer field into his intraservice VAS-application. 

The second stage is the cancellation of value units represented by VAS-data. A 
VAS-provider introduces value units into the VAS-data by means of a special key for 
entering data. The value units may be consumed by interservice partners who have 
available a key for unit cancellation obtained from the overall responsible VAS- 
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provider. In this stage partners having mutually different rights interact with non- 
public VAS-data. 

The third step is the direct data entry access to the VAS-data by all participating 
interservice partners. This method requires an appropriate degree of trust between 
the parties, because VAS-data can be modified without limitation. 

The transfer field serves as a connecting link between VAS-applications. Data in the 
transfer field are generated by the VAS-applications in the VAS-container. Data may 
also be entered directly into the transfer field if the person doing so operates no 
VAS-application of his own in the VAS-container. 

The transfer field is in principle available to all applications, however, entries may 
only be made by whoever is entitled thereto (by a key). Only receivers who are 
entitled thereto in terms of the regulations, i.e. the Rules and Regulations R&R may 
remove data from the transfer field. The receiver checks for the presence of transfer 
data addressed to him and withdraws these for processing in his own system. 

In order to prevent the manipulation of transfer data in a public interchange, the 
generator introduces an authenticity feature and the VAS-container introduces a 
sequence number. The uniqueness of a transfer report is secured by these 
elements and the origin of the data is demonstrated. 

In case of need, the receiver of transfer data is furnished by the generator with the 
means for performing an authenticity check. If this is not desired, the acceptance of 
the data may take place in good faith; in that event, the authenticity feature may 
possibly only be checked when accounting takes place in the basic system of the 
generating VAS-provider. 

The withdrawal of data from the transfer field is possible only once without loss of 
an authenticity feature. On withdrawal, the data are marked and remain (as a copy) 
in the transfer field. This permits proof of the transfer procedure even after the 
withdrawal of the data for a certain period. 
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Data in the transfer field carry an expiry date. Expired data may be overwritten when 
required by arbitrary applications. The data in the transfer field may be marked on 
withdrawal thereby to be freed for immediate overwriting. Should the transfer 
storage nevertheless be completely filled before the expiry of a set of transfer data, 
the cardholder must delete no longer needed entries at the service terminal. 

For the modelling of VAS-applications 3 operations are defined. These operations 
act onto the VAS-data. Loading and deleting of applications are functions of the 
VAS-container and are not considered in the following paragraphs. 

Purchasing: In general, the purchase of an entitlement to services and the filing of 
proof thereof in the VAS-data of a VAS-application. 

Cancelling: Generally the redemption of the entitlement without or with complete or 
with partial consumption of VAS-data of an application. The procedure 
generates an electronic receipt which is filed in the transfer field. This 
receipt bears an appropriate expiry date by which it may be deleted 
from the transfer storage. 

Withdrawing: Generally the retrieval of the electronic receipt from a transfer field for 
further processing (e.g. basic system). A copy of the receipt remains 
and serves as proof of the "cancellation". 

"Acquiring" of VAS-data may only proceed through the respective VAS-provider. 
"Cancellation" of VAS-data may take place only by way of the VAS-provider who 
generated these by "purchasing" or by an interservice partner authorised thereto by 
the VAS-provider. "Withdrawing" may be performed also by any other VAS-provider. 
An interservice without equal rights of access to the VAS-data causes triggering the 
status transition "withdrawing" by the partner. The electronic receipt thereby 
recovered may then be accounted for by way of the system operator and the basic 
system of the VAS-provider. "Purchasing" and "cancelling" may take place in a 
single step. 
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VAS-applications with common features may be subdivided into classes. These 
classes constitute the basis for data structures in the VAS-container. The VAS- 
provider during the implementation of his application selects an application class. 

In this context the following application classes are defined: 

• Points database 

• Ticket 

• Identification document 

• Voucher 

• Database 



Points database denotes an application class in which an account of points values is 
administered. Onto and from the points account values may be credited and 
withdrawn. The crediting of values proceeds through the VAS-provider in that the 
database has entered thereinto the new accounts balance. The debiting of values 
proceeds by way of the "cancellation" operation in which context an electronic 
receipt is filed in the transfer storage as evidence. Access to the two functions is 
brought about by two different access keys. 

Ticket denotes an application class in which a value field exists which may be 
cancelled and thereby consumed either once or several times. Crediting of values in 
the application class Ticket is performed once only. 

Identity document denotes an application class in which the VAS-data receive 
evidence of an entitlement. The evidence is generally not cancelled by use; 
however, after predetermined criteria, e.g. after an elapse of time, it becomes 
invalidated. Depending on the definition of the application the authenticity of the 
identity document (e.g. neighbourhood parking authorisation) or the act of 
presenting the document is documented (e.g. collective taxi trip using a monthly 
ticket: Generation of an electronic receipt by the card. The receipt is submitted by 
the taxi enterprise to the public transport corporation and is accounted for pro rata). 
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Optionally the usage of the identity document may be documented in the transfer 
storage of the card by electronic receipts. 

Voucher denotes an application class by means of which the service entitlement (as 
a rule for short duration) is placed in an interim store of the card. These electronic 
vouchers are stored exclusively in the transfer storage of the VAS-container. The 
application utilising the voucher is, as a rule, different from the generating 
application. The withdrawal of the voucher from the transfer store is possible once 
only and is documented by the card. An authenticity feature generated by the VAS- 
container may by used during accounting in the basic system. 

Data memory denotes an application class in which a VAS-provider stores data in a 
VAS-container to provide an additional service for the client (e.g. last menu in a fast- 
food restaurant, last number pool numbers, service preferences, proposal lists). 
These data are for information only and represent no claim to services against the 
VAS-provider. Access to the data is controlled by the VAS-provider. 

Each application class is characterised by a typical user cycle. The following table 
illustrates the frequency at which the three above defined operations are applied to 
the VAS-data of the application class (Please note: "Purchasing" does not mean 
"loading application" and "withdrawing" does not mean "deleting application"). 

Table 1 - User Cycle 



Purchasing 

Cancelling 

Withdrawing 



Points 

database 

Multiple 

Multiple 

Multiple 



Ticket 

Single 

Multiple 

Multiple 



Identity 

Document 

Single 

Multiple 

Multiple 



Voucher 

Single 
Single 
Single 



Data memory 

Multiple*** 

Never 

Never 



*** In the application class "data memory" no entitlement is acquired, the application 
merely enters data into the application. 
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Fig. 4 illustrates the above listed application classes and operations by way of a 
transaction model. 

In the following the security architecture of the chip card according to the invention 
will be further dealt with. In order to ensure security the following keys are defined: 



Table 2 - List of Keys 



Name 


Place 


Holder 


Description 


Kso 


VAS-container 


System operator 


Key for administering the VAS-container 




VAS -container 


System operator 


Key for authentication of the VAS- 
container 


KsiG VASC 


VAS-container 


System operator 


Key for encoding the transaction data 


KGK^c 


VAS-container 


System operator 


Key for the derivation of the KGK DFD mx 


Klvasp 


VAS-application 


VAS-provider 


Key for writing access to VAS-data 


Krvasp 


VAS-application 


VAS-provider 


Key for reader access to VAS-data 




VAS-provider 


VAS-provider 


Key for the derivation of K D ^ C 




Dealer terminal 


VAS-provider 


Key for authentication of the trader 
terminal 



The security architecture is based on the life cycle of the VAS-container or VAS- 
applications and is stratified according to the responsibility of the participating 
instances. An explanatory schematic illustration is apparent from Fig. 5. 



In what follows, some elucidations of the structure of the VAS-containers as well as 
of the applications applied thereon are provided. 

The VAS-container as well as VAS-specific supplementary commands are either 
applied onto the card by the issuer jointly with other non-VAS-applications or at the 
latest are integrated at a service terminal by an authorised VAS-provider into an 
existing card platform at a service terminal. 

For the second possibility the following mechanism may find application: The system 
operator agrees with the issuer on a temporary key K^*. The issuer opens the card 
with his key which is only known to him. establishes the files of the VAS-container 
and in particular writes the K so * into the DF_VAS. The system operator may then at 

?.<> 
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a later instant (e.g. the card enters into contact with a service terminal for the first 
time) replace the key Kso* by his own key Kso which is then only known to himself. 
The system operator may now himself enter further data such as. for example, the 
KGKo EC or may himself in the case of a platform with dynamic memory 
administration generate or delete files for VAS-applications. It is thereby ensured 
that the issuer after the first use of a VAS-card no longer has access to the VAS- 
container and that the system operator only has access to the VAS-container. 
Because of the absence of any common data structures and data interchange with 
other applications, the security architecture of the VAS-container is thus 
independent of other applications present on the card platform. 

In a special embodiment of the invention use is, however, to be made of the first 
possibility: The issuer is required on instructions of the system operator to apply the 
VAS-container including all keys onto the VAS-cards. 

The VAS-container consists of a predetermined data structure, predetermined 
access conditions (Acs) and some global data. The global data contain inter alia the 
key K so for loading or deleting of VAS-applications. It is ensured by way of this key, 
known only to the system operator that only permitted VAS-applications can be 
loaded. For this purpose the card requires an external authentication by the system 
operator via K so . 

Whenever a cardholder wishes to load a VAS-application at a service terminal, the 
applicable VAS-provider instructs the system operator accordingly to do this on his 
behalf. When loading the VAS-application into the VAS-container the VAS-provider 
transfers the keys K LVASP and to the system operator who then enters these 

into the application. The key K^^p permits the VAS-provider to protect data of the 
application against written access and in additional internal data against reading 
access. For this purpose the card requires an external authentication of the VAS- 
provider based on K^^p; i.e. the card checks actively the authenticity of the 
terminal. After successful performance of this function, a terminal is permitted 
written access to a VAS-application and reading access to internal VAS-data of the 
application. An internal authentication, i.e. checking the VAS-application (and 
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thereby the card) as to authenticity by way of the dealer terminal, may take place 
optionally. When the VAS-application is used by the cardholder, these internal VAS- 
data may be written into the application or be modified at optional terminals which 
have access to the key K,. VAS p. The function "purchasing" is supported therefor by an 
UPDATE RECORD command which must be preceded by an external 
authentication by means of the key K,. VAS p. 

Reading access to all non-internal data of the VAS-application is only permitted if a 
previous external authentication by K RVASP or by K*, or by the correct entry of a PIN 
or a password by the system operator has taken place. The PIN/password protected 
access is provided in order to permit the cardholder to inspect data at the terminal or 
at the wallet. The cardholder may elect at a service terminal to activate or deactivate 
a PIN/password protection for reading the value or status data. 

The global data of the VAS-container are associated with a key Kg^ VASC for signing 
data extracted from the transfer field. By way of the signature the intactness of these 
transaction data can be checked whenever they have to be transferred protected 
against manipulation between interservice partners for mutual accounting. In 
addition to a signature optionally introduced by way of the interservice partners, a 
signature based on K S10 VASC and a transaction counter administered by the VAS- 
container are added for sets of data which the card issues by way of the operation 
"withdrawing". Because on the one hand reading of the transfer field is permitted by 
any one but, on the other hand, the signature of the card via K SK3 VASC can be 
generated only when calling for the operation "withdrawing" (and this can happen 
only once) any unpermitted double accounting for vouchers is recognised. Each 
interservice partner is able to have the authenticity and uniqueness of a withdrawn 
voucher acknowledged by the system operator. In addition, the authenticity of the 
VAS-container can be verified by checking the signature by the system operator. 

In the event that a card platform employs asymmetrical key procedures, it is possible 
also to employ as Ks IG VASC a private (secret) key within the card for signing purposes 
or to derive such a key from a private Key Generating Key. The VAS-providers may 
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in such case employ public (non secret) keys for themselves checking the signature 
without having to consult the system operator. 

Part of the data of the VAS-container is formed by a global Key Generating Key 
KGKoec. which has the ability to generate the access key Ko EC for all terminals of all 
VAS-providers for the authority check for the operation "cancelling" (the subjects key 
derivation and checking will be dealt with again further below). The cancellation of 
monetary value data are not subject to the same security measures as the loading 
or purchasing of an entitlement. For this purpose it is sufficient to use a global key 
instead of a key specific to the application. This global key is converted initially by 
derivation into an application key and thereafter by renewed derivation into a 
terminal key. The VAS-provider is only informed of the application specific derivation 
of the global key for generating the own terminal key. This is described briefly in 
what follows: 

We denote as mac(k, d) the calculation of a message authentication code for a 
message d and a DES-key k by means of DES. As long as the message is no longer 
than 8 bytes this corresponds to the codification as such (presupposing ICV=0). We 
denote as macp(k, d) the calculation of mac(k, d) with subsequent adaptation of the 
parity bits. The result k' = macp(k, d) is once again a valid DES key. 

The calculation of the application specific terminal key then proceeds as follows; 

1 . Each card stores a key 

which is equal for all cards and which is kept secret by the system operator. 
The system operator provides that this key is personalised Into the card. 

From this key all other VAS-application and terminal keys can be derived. 

2. A VAS-provider wishes to introduce a VAS-application A with 
AID A =RID VAS .PIX A . The system operator now calculates from the key KGK 0EC 
and the PIX the application specific key 
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KGKcecpw^macpfKGKoec, PIXJ 
and hands this key over to the VAS-provider. 

3. This VAS-provider, by means of their terminal ID derives from KGK OEC p, x for 
all terminals which the TRANSFER command is supposed to apply to the 
VAS-application A, their specific keys: 

K oec =macp(KGK oec>P(Xl Terminal ID) = 
macp(macp(KGKo ECl PIX*), Terminal ID) 

The VAS-provider stores these keys in his terminals. In the event that the 
VAS-provider does not himself operate the terminals, he generates the keys 
and distributes these to the operators of the terminals. 

4. The VAS-card only performs the TRANSFER command if the command 
comprises a cryptogram C generated by the terminal which is formed by way 
of specific data data of the message in the transfer storage. The card itself 
recognises KGK 0 g C and obtains from a terminal besides the user data data 
and the cryptogram C the terminal ID as well as the PIX (or alternatively the 
card itself knows the PIX, for which see also the description of the command 
TRANSFER). The card is now able to calculate the cryptogram C by way of 
the user data: 

mac(macp(macp(KGKo ECl PIX) t Terminal ID),data) = 
= mac(macp(KGK 0ECPlx , Terminal ID),data) = 
= mac(K oeCl data) = 
= C 

The card now compares the cryptogram C calculated by itself with the cryptogram C 
calculated by the terminal. If they differ, there takes place a termination of the 
transaction and a fault report. In the case of congruence the VAS-card will execute 
the TRANSFER command. 
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The various security measures are in line with the different constructions of service 
terminals or dealer terminals (for loading or purchasing respectively) and simple 
dealer terminals (for cancelling). In order to perform the "cancellation" operation a 
terminal must authenticate itself to the card by having knowledge of a K^. If that 
ke Y Koec ^ compromised, the aggressor can merely perform the function of this 
single terminal. However, this procedure is recorded in the card. The documentation 
contains an unambiguous sequence number, the cancellation and the terminal ID. 
The VAS-applications utilise the security services of the VAS-container in order to 
regularise access to VAS-data. The execution of VAS specific functions is limited to 
authorised parties by the definition of access rights. 

In general, it is necessary that for each VAS-application publicly accessible data 
regions (e.g. for reading of values by means of a wallet) and private data regions of 
the responsible VAS-provider are available which the latter may protect against 
access by third parties (e.g. internal administrative data). 

Having regard to the fact that according to ISO 7816-4 cards do not provide 
differentiated access protection for individual Records of Elementary Files (EF), it is 
necessary to use a plurality of files, each containing a record for displaying different 
sights on a VAS-application. 

Thus, for the application classes points store, ticket, identification document and 
data memory differentiated access protection may be brought about by subdividing 
the VAS-data into four Elementary Files as illustrated in Fig. 6. 

The four Elementary Files contain the following data or are protected in the following 
manner: 
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Table 3 - Summary of Files 



Field 


Contents 


Typical Usage 


Access protection 


EF_KEY 


Contains the key 

KLVASP. k RVASP which 
Is known only to the VAS- 
provider 

(remark: for each VAS- 
application and optionally 
for each card the VAS- 
provider provides a single 
pair of keys) 


A VAS-provfder must 
authenticate himself via 
KLVASP. 9^ t° being 
permitted to write VAS- 
data into EF INFO. 
EFJNTERNAL and 
EF_ VALUE, respectively 
before he is permitted to 
read data from 
EFJNTERNAL 

A terminal must 
authenticate itself by 
means of KrvaSP before 
being permitted to read 
VAS -data from EF INFO, 
EF VALUE 




EFJNFO 


Non-internal information 
by way of the VAS- 
ap plication 


• Ticket information 

• Bonus programme 
information 

• Identity document 
Information 

• Parking ticket 
information 


The contents of these 
data units can only be 
written by the VAS- 
provider (external 
authentication by 
knowledge of K|_v^sp). 
Reading should only be 
possible at terminals 
having access to 

K RVASP & K$Q. 0f tf tno 
cardholder enters a 

correct PIN. (The PIN 

protection may be 

deactivated by the 

cardholder) 


EFJNTERNAL ! 


Internal data of the VAS- 
application 


Internal counters, 
statements of account, 
tax Information, additional 
keys for 

• Bonus programmes 

• lj is count scales 

• Hidden identification 
features 

• Codes 


The contents of these 
data units can only be 
written and read by the 
VAS-provider. Access 
protection is based on 
external authentication by 
knowledge of K^v/ASP 


EF_VALUE 


Value units of VAS- 
application 


This data unit contains 
accountable values of a 
VAS-provider application. 

• Statement of account 

• Residual value 
public transport ticket 

• Credit 

• User counter 


Only the VAS-provrder 
can write these data 
explicitly (external 
authentication by 
knowledge of KRVASP)- 
Implicitly the value can be 
reduced by the command 
"cancel" by a partner who 
has been entitled to 
perform the function by 
the VAS-provider (by 
signature of the operation 
cancelling with KqeC)- 
Reading as for EF INFO. 
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This structure of Elementary Files (EF) supports the same differentiated rights of 
access for all application classes. 

8earing in mind that application classes are now combined in a single 
implementation class which lays down the number and size of the Elementary Files, 
waste of storage capacity due to different space requirements for applications may 
be minimised. The application classes points storage and ticket require the same 
resources EF_KEY, EFJNFO, EFJNTERNAL, EF_VALUE and are therefore 
combined in an implementation class "DF_PT\ For the application classes identity 
document and data memory the Elementary Files EF_KEY and EFJNFO suffice 
and are therefore combined in the. implementation class M DF_AD". Considered in 
terms of numbers: There are p objects of the implementation class DF_PT and a 
objects of the implementation class DF_AD in the VAS-applications of the 
application classes point storage and ticket, respectively identification document and 
data storage can be loaded. 

Specifically for the application class voucher, which should provide for public reading 
access for all VAS-participants for purposes of joint data interchange, the 
implementation class transfer field is used. Writing access is exclusively possible 
indirectly by the application of the TRANSFER command which presupposes a 
signature with a correct K DEC . This implementation class consists of exactly one entry 
in Elementary File EFJTRANSFER belonging to the global data of the VAS- 
container. The objects of this class are records in this file. We refer to this 
implementation class also as "EFJTRANSFER". 

The implementation classes illustrated in Fig. 7 exist within the VAS-container. 
These implementation classes form the storage model of the VAS-container. 

The storage model may be made available in two manners. The nature depends on 
the card platform: 

Fixed partitioning of the storage region for the VAS-container: 
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For the implementation classes DF_PT and DF_AD a maximum number p or a, as 
the case may be, of objects is fixed by the issuer and is loaded by the issuer onto 
the card using CREATE FILE commands. The objects are denoted as DF_PT and 
DF_AD respectively. VAS-applications may be loaded later on into free objects, i.e. 
not occupied by other VAS-applications. For loading or deleting VAS-applicatipns 
UPDATE RECORD commands only are then necessary. 

Thus the issuer fixes the number of possible objects of the two implementation 
classes according to his own requirements; these may, however, differ from the 
actual VAS-user pattern of the cardholder. The subdivision is maintained over the 
entire life cycle of the card. A VAS-application is loaded into an object belonging to a 
suitable implementation class. Thus, for example, a VAS-application representing an 
identity document, may also be accommodated in an object of the implementation 
class DF_PT, if no (more) objects of the implementation class DF_AD are available. 
The assignment of a VAS-application to an object takes place by entering a tripel 
(PIX of the VAS-application, FID of the loaded object, clear text name of the 
application) into the global database EF_DIR of the VAS-container. The removal of 
the application corresponds to the removal of this tripel from EF_DIR and the 
destructive reading (by UPDATE RECORD commands) of the memory loaded with 
the application. 

This modification is used with card platforms which do not support dynamic 
generating or deleting of DF/EF structures. 

Dynamic setting up of objects of the implementation class: 

For each VAS-application to be loaded the files are set up by CREATE FILE 
commands as required for the underlying implementation class. When deleting the 
VAS-application, the DF/EF occupied by it. is removed entirely from the card and the 
storage space is freed. The maximum number of objects of implementation classes 
is not here explicitly determined by the issuer and depends only on the storage 
capacity of the card available. 
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This modification presupposes a dynamic database administration by the card 
operating system. 

In the next following working example we will start off from the first modification, 
because the second one makes higher demands on the available card platform. 
However, if a dynamic memory administration is available and it has been assured 
that more storage capacity can be saved by the dynamic setting up of objects than 
corresponds to the administration costs, the existing concept may be adopted and 
offers more flexibility to the cardholder. 

In the following the data structures and commands are presented by means of which 
the VAS-container and the functionality of the VAS-client card can be practised as 
compared with other system components. Moreover, VAS-operations are laid down 
for typical business situations which describe the respective interaction between the 
VAS-container and terminal. 

The following preconditions apply to the implementation: 

Each card, regardless of the platform, makes available to the dealer terminal 
the same data and command interface. Accordingly, the required commands 
are clearly described in their codification. 

• Service terminals are able to recognise the card platform. The functionality 
can therefore be attained by specific commands of the platform. Accordingly, 
these transactions are written partly informally. The manner in which this 
function is provided, is left to the card manufacturer. 

In Fig. 7 a variety of implementation classes of the VAS-container is schematically 
illustrated in this context. Fig. 8 shows schematically the data structure of the VAS- 
container, Fig. 9 shows schematically the data structure of the implementation class 
DF_PT, Fig. 10 shows the data structure of the implementation class DF AD. 
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Access to the files of the VAS-container is restricted explicitly by the following 
access conditions (AC): 

Table 4 - Access conditions 



Database 

OF VAS 
EF ID 
EF DIR 
global KEYs 
PIN 


Admin 

Kso 
Kso 
Kso 
Kso 
Kso 


Reader access 

NEV 

ALW 

ALW 

NEV 

NEV 


Writing access 
NEV 

*so 

-&b 

Kso 


EF VERSION 
EF SEQ 

ef"transfer 

DF X 

(X=PT, PT 0J AD„... 

ADJ 
EF KEY 


Kso 

Kso 
Kso 

Kso 
Kso 


ALW 

ALW 
ALW 

NEV 


Kso 

Kso 

Kso 

NEV 


EFJNFO 


Kso 


NEV 

PIN or Kovasp 
or ^ 


Kso 
Klvasp 


EF INTERNAL 


Kso 


Kcvasp 


Klvasp 


EF_VALUE 


Kso 


PIN or Kpv^p 
orK so 


Klvasp 



In this context the AC have the following meaning: 

ALW (Always) = Access of the command to the database is always permitted. 

NEV (Never) = Access of the command to the database is never permitted. 

Kgo = Prior to access external authentication of the system operator by way of 
the key must take place. 

k lvas? = Prior to access external authentication of the VAS-provider by way of 
the key K^^p must take place. 

Krvasf " Prior to access external authentication of a terminal authorised by 
the VAS-provider must take place by way of the key K RVASP . 
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• "PIN = Prior to access the correct PIN must be entered by the cardholder and 

be transmitted in clear to the card by the command VERIFY. 

♦ PIN or Kflvasp or Kso = Prior to access either the correct PIN must be entered 
by the cardholder or an external authentication by the VAS-provider using 

or by the system operator using must take place. 

In this context it should be noted that the Or-Iinking of access rights as denoted 
above, in the card operating system is, as a rule, not provided. Where applied, this 
might involve special implementation costs (alternative: special READ command 
with implicitly fixed security attribute). 

Data fields within the records of Elementary Files are differentiated according to the 
following formats: ASCII, Binary, BCD, Date, Format string. 

Data elements of the type "format string" contain VAS-data in packaged 
presentation which can be displayed to the cardholder at the terminal. 

For optimal data storage utilisation clear text and binary data are mixed and 
rendered displayable by way of formatting macros. 

All Elementary Files (EF) of the VAS-container are defined according to ISO 7816-4 
as linear formatted EF databases with records of constant length {linear fixed record 
files). 

The Elementary File EFJD of DFJ/AS consists of a record which contains the VAS- 
container ID. 

The Elementary File EF_DIR of the DF_VAS consists of nr^n records. For each 
VAS-application loaded into the VAS-container its proprietary identifier extension 
(PIX) and its physical storage site (FID of the DF_X into which the application has 
been loaded) is fixed in a record of the EF_DIR. The PIX identifies, e.g. as a code 
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number, the application and the service provider to which the application has been 
assigned. 

The entries in EF_DIR are dynamically set up at the service terminal of the system 
operator. Records without entry are set up with an empty TLV object '61'. 

When loading a VAS-application a free storage region for the appropriate 
implementation class is sought, certain VAS-data are there entered and finally a 
new record is generated in EF_DIR. 

When deleting an application, an empty TLV object must accordingly be written into 
EF_DIR. 

The Elementary File EF_VERSION of DF_VAS consists of a record which contains a 
version number of the VAS-container. 

The version number may be utilised by the terminal in order to differentiate between 
different VAS-container modifications and/or different software versions. 

The Elementary File EF_SEQ of DF_VAS consists of a record which contains the 
number of the next transfer field entry. 

The sequence number is read out by the supplementary command TRANSFER. 
This command then generates in the transfer field EF_TRANSFER a record into 
which inter alia the sequence number from EF_SEQ is transfened. Jointly with the 
command TAKE which assures that each record from the transfer field is withdrawn 
once only and which records this withdrawal by signature via the sequence number, 
the once only withdrawal of (original) vouchers or receipts can be assured. 

In the following, the transfer storage is to be dealt with in more detail. 

The transfer storage is set up within the VAS-container and comprises nr e? TPUNSFe; , 
records. Entries in the records of these files contain transfer data generated by the 
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TRANSFER command. The data interchanged between VAS-applications as well as 
the storage of VAS-data of the class Voucher is performed by way of the transfer 
storage. 

The transfer storage can be read without restrictions, however, the writing access is 
possible only by way of the VAS-specific command TRANSFER and TAKE. 

Loading the data fields by the TRANSFER command proceeds by a 'last-recently- 
used' algorithm in the card. The oldest record in the database can be determined by 
searching for the lowest value in the first 2 bytes of the record. 

Data fields may be marked by the command TAKE" in the transfer storage as 
withdrawn and/or removed. In each case the deleting of data in the transfer storage 
takes place by overwriting with new data. 

Each record in the transfer storage contains, for example, an expiry date, the 
terminal-ID, the PIX, the sequence number and optionally further data. 

Each Elementary File EFJNFO within lists DF_X (where X = PT„ .... Pt p , AD 1t 
AdJ comprises a record containing the expiry date as well as general VAS-data of a 
VAS-application. For example, the nature of a ticket (single or multiple ticket) or the 
boarding locality may be entered here. EFJNFO must, however, contain at least 
one clear text name of the application which can be read for the operation viewing 
VAS-applications. Sensible data must first be protected by the VAS-provider by 
suitable external key algorithms. 

This EF is readable if an external authentication with K so or K RVASP takes place or 
where the cardholder, in the case of an activated PIN-protection enters a correct 
PIN. 

Each Elementary File EFJNTERNAL within records DF_X (where X = PT, PT p , 

AD n ADJ consists of a record which may contain internal VAS-data of the VAS- 

V) 
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provider concerning its loaded VAS-application. Neither the cardholder nor any other 
VAS-provider can read these internal data. 

Each Elementary File EF_VALUE within records DF_X (where X = PT„ .... PT„, AD„ 
.... AD a ) comprises a record which may contain an integer value field of the VAS- 
data. This EF can be read if an external authentication with K^ or takes place 
or the cardholder in the event of an activated PIN-protection enters a correct PIN or 
a correct password. 

The following key fields are used by the VAS-container or by the VAS-application. In 
the following we will start from a pure DES-codification. I.e. all keys of the VAS- 
container are DES-keys and are coded in 8 bytes (including parity bits). 

Within the VAS-container and within the VAS-applications the following keys 
referred to by their KID (Key Identifier) may be referenced: 



Table 5 - Keys VAS-container 



KEY 


KID 


Kso 


•00' 


Ka.ut 


•or 


KsKSVASC 


•02' 


KGKoec 


'03' 



Each key is coupled to a faulty operation counter. This registers failed authentication 
attempts with this key and blocks a further use once a limit entered for this counter 
has been attained. 

Within the VAS-application the following keys can be referenced by their KID. 

Table 6 - Keys VAS-application 



•so 
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KEY 


KID 




'04' 




•05' 



Each key is connected to a faulty operation counter. This registers failed 
authentication attempts with this key and blocks any further use once a limit entered 
for this counter has been reached. 

The VAS-container contains a personal identification number or password (PIN). 
This is used for identification of the cardholder by way. of the VERIFY command. The 
PIN is connected to a faulty operation counter which registers each false input and 
which on attainment of a limit blocks the PIN-comparison. This blockage can be 
turned back by the system operator using suitable administration commands. The 
faulty operation counter is turned back once the correct PIN has been entered. 

The following parameters exist for the VAS-container which may be selected by the 
card issuer in accordance with space available on a card platform and his individual 
wishes: 

• p Maximum number of objects of the implementation class DF_PT 

= maximum number of VAS-applications of the application classes Points 
Storage and Ticket which can be loaded into a VAS-container simultaneously; 

• a Maximum number of objects of implementation class DF_AD 

= maximum number of VAS-applications of the application classes Identity 
Document and Data Storage which can be loaded simultaneously into a VAS- 
container; 

nr 0IR Maximum overall number of objects: nr 0IR = p + a 
The number of records in EF_DIR is nr 0IR 

"^transfer number of records t of the EF_TRANSFER 
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The storage requirements for the data of the described Elementary Res h 
follows: 




ft- 



A2 
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Bytes 

Global data of the VAS-container: EFJD 4 

EF_DIR 9*(p+a) 

EF_VERSION 1 . 

EF_SEC 2 

Global Keys, Pin 64+2 

Transfer field: EF_TRANSFER 48 * nr^ TfUNSFEn 

Proprietary Data of the VAS- EF_KEY (p+a) * 32 

provider: EFJNFOR (p+a) * 62 

EFJNTERNAL - : p*10 

EF_VALUE ^ ^ p*3 



If we select, e.g. for the parameters p, a and nr^ trammer the following values, then 
the following minimum storage requirements for the VAS-container (without storage 
requirements for supplementary commands) arise: 

Parameters Storage requirements 

p = 8, a = 3, nr^TRANsren = 15 2030 bytes 

p = 1 0, a = 5, n i*ef jtransfer = 20 2758 bytes 

The maximum storage requirement is probably higher than the minimum storage 
requirement by about 10%. 

In the following the commands of the chip card according to the invention will be 
dealt with in more detail. 

The READ RECORD command is used for reading out data from lineary Elementary 
Files. The card in its reply supplies the contents of the records. The EF is referenced 
by the Short File Identifier (SFI). 

The status code '9000* signals a successful performance of the command; any 
different code is considered an error. 
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The UPDATE RECORD command is used in order to enter data into the records of 
a linear EF. the command message contains the reference to the ER the record 
and the data. 

The response of the card contains the status code. The status code , 9000 l signals 
the successful conclusion of the command. Other status codes indicate an error. 

The GET CHALLENGE command requires from the card a random number. The 
random number is used in conjunction with the dynamic authentication in 
EXTERNAL AUTHENTICATE. 

The response message of the card contains a random number, 8 bytes long, and 
the status code. The status code '9000' indicates the successful performance of the 
command. Any different status codes indicate an error. 

The command EXTERNAL AUTHENTICATE permits the authentication of a terminal 
against the card. The EXTERNAL AUTHENTICATE is used within the context of 
VAS-applications for authentication of the system operator and the VAS-provider. 
EXTERNAL AUTHENTICATE transfers a cryptogram into the card which prior to this 
has to be generated by the terminal by encodification of a random number. The card 
compares the cryptogram with a reference value which it has itself calculated using 
the same procedure. If both values are equal, the card notes internally that the 
access condition authentication for this key has taken place. If the comparison 
should turn out negatively, the card will issue the status M non authorised" and 
decrements an internal faulty operation counter. Once this counter reaches the 
value 0, any further performance of the EXTERNAL AUTHENTICATE is blocked 
with the status "authentication blocked". 

The response message of the card contains the status code. The successful 
performance of the command and the authentication of the terminal in relation to the 
card is indicated by the status code '9000'. Any different status codes indicate an 
error. 
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The command INTERNAL AUTHENTICATE is used in order to check the 
authenticity of the VAS-container by a terminal. The card for this purpose calculates 
a cryptogram by way of reference data derived from the terminal. The terminal in its 
turn forms the cryptogram and compares it with the value of the card. In the event of 
equality the terminal can assume the authenticity of the VAS-container. 

The response of the card contains the cryptogram and the status code for the 
Execution of the command. The successful execution of the command is indicated 
^ by the status code '9000\ Any different status codes indicate an error. 

The VERIFY command is used for verifying the cardholder PIN. The command 
transfers the PIN data uncodified to the card where a comparison with a stored 
reference value is performed. If the entered and the stored value are identical, the 
access conditions "PIN" are considered complied with. 

The response message of the card contains the status code. The status code '9000' 
indicates a successful execution of the command. Other status codes indicate an 
error. 

The TRANSFER command generates an entry in the transfer storage. Three 
v - operating modes are defined for the command: 

1 . Generation of an entry in the transfer field by reduction of values in the 
EF_VALUE field of the application of the class Ticket or Point Storage. 

2. Generation of an entry in the transfer field by creation of a receipt in 
application of the class Identity Document. 

3. Generation of an entry in the transfer field by generating a voucher in 
applications of the class Voucher. 

The operating mode is automatically selected by the card: If the command is 
executed within a selected application-DF, the presence of an EF_VALUE is first 
checked for. If the EF_VALUE is present, the card executes the command in mode 
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1 , alternatively in mode 2. If within the VAS-container no application-DF has been 
selected, mode 3 is used. 

The terminal, when calling for the TRANSFER command, furnishes the card with the 
following data: 

• Current date 

Expiry date for the entry in the transfer field 
Identification for the terminal which generates this entry 

• User data for the transfer field 

PIX of the VAS-application (mode 3 only) 

• Number of units to be subtracted (mode 1 only) 

MAC concerning the abovementioned data, the sequence number and the 
VAS-container number. 

The card, once the TRANSFER command has been called up, performs the 
following sequence: 

1 . Searching for a free entry in the transfer storage, (The following list provides 
in reverse order the priority in which existing entries are to be overwritten: 
"Entry marked as removed", "entry marked as withdrawn" and "expiry date 
reached", "expiry date reached"). 

2. Attaching the PIX to the data of the terminal in modes 1 and 2. 

3. Attaching the sequence number to the data from step 2. 

4. Attaching the VAS-container ID to the data from step 3. 

5. Deriving the KGKo ECPIX by encoding the PIX under the KGKq EC . 
6.. Deriving the Ko EC by encoding the terminal ID under KGK DEC PIX . 

7. Generating the MAC by way of the data of step 4. 

8. Comparison of the MAC from step 7 with the MAC of the terminal. If the 
values are different, the card interrupts the function and reduces the faulty 
operating counter for the KGK DEC . 

9. For mode 1: Testing the value field EF_VALUE in the register into which the 
application had been loaded. If insufficient units are present in this field, the 
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' card interrupts the function at this point Otherwise the value field in the 
application is reduced by this amount. 

1 0. Assembly of the command message. 

11. Incrementation of the contents of EF_SEQ by 1 . 

The command message contains, for example, fields including an expiry date, the 
terminal ID, the transaction data, a field for the operating mode (contains, e.g. in 
mode 3, the PIX), as well as a cryptogram. 

The cryptogram is calculated using the key Ko EC , the data formed by way of the 
MAC, for example, embracing the transaction data and the terminal-ID. . 

The response message of the TRANSFER command includes, when successful, a 
data field 8 bytes long and the status code •9000' which Is 2 bytes long. Reply 
messages with a status code differing from '9000' are interpreted as error codes. 
The data field of the reply message contains in the error free situation, (i.e. in 
particular the cryptogram of the command message was correct) the cryptogram 
encoded with Ko 6C of the command message. In this manner (instead of an internal 
authentication using K^) an authentication is performed implicitly by the VAS- 
container. 

The command TAKE serves for the withdrawal of objects from the implementation 
class EF_TR AN S FE R . Technically, the execution of the command TAKE means the 
reading out of a record to be denoted from the storage EFJTRANSFER, the record 
being retained in the storage for so long until the storage space is required for a new 
entry, the set of data being marked as withdrawn. Considered technically, anybody 
can use the command TAKE in order to withdraw a set of data, however, according 
to the R&R only a VAS-provider for whom the set of data was intended, should do 
this. 

For the removal procedure the following may be assumed. The VAS-provider who 
wishes to remove a voucher or a receipt, searches the transfer storage for a suitable 
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set of data (e.g. by the command SEEK or by explicit reading of each record). The 
set of data will in any event be read and its contents may be checked. 

A display of the set of data in the response is therefore not necessary. It may 
furthermore be assumed that the number of the record is known. 

The command TAKE provides for the following modes: 

Removal with simultaneous annotation that the data have been invalidated 
Removal without the aforesaid annotation. The data remain valid. 

The command message contains fields with terminal-ID, PIX of the application and a 
random number generated by the terminal. 

The PIX in the command denotes the application which removes the data. It may 
differ from the PIX of the set of data which is being removed. It serves exclusively for 
the derivation of Ko E c of the dealer terminal which effects the removal. 

The response message of the card contains a cryptogram C, with Ks IQ . VASC 
concerning the data of the records of the transfer field reported in the command 
message and the VAS-container ID, a cryptogram C 2 with Ko EC of the terminal 
effecting the removal via C, and the random number taken from the command 
message. The response message, in addition, contains the status code. The key 
Kjj EC is derived as described further above. Authenticity is implicitly proved by the 
VAS-container by virtue of the cryptogram via K 0EC . Proof of authenticity and 
uniqueness is calculated by means of the cryptogram C (since C is formed by way of 
the sequence number, removal bit of the transfer field record and the VAS-container 
ID) which can be verified by the system operator. 

The status code "9000' indicates the successful execution of the command. Different 
status codes are interpreted as errors. 

It is to be assumed that the SO requests one AID VAS according to IDO/IEC 7816-5. 
More specifically: He requests an RID VAS , 5 bytes long for the VAS-system. 
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The AID VAS of the list DF_VAS is to read: AID VAS = RID VAS .PIX 0F VAS . 

For each VAS-application A a Pix A , 3 bytes long, is issued in accordance with R&R 
in order to identify the former unambiguously within the VAS-container via AID A = 
RID VAS .PIX A . After the selection of DF_VAS a list in which the VAS-application A is 
contained, may be selected using SELECT FILE < PIX A >. 

The UPDATE KEY (KID, K) denotes a command which depends on the card 
platform by which a key is replaced by the new value K using the Key Identifier ID. 

Before a VAS-application out of one of the implementation classes DF_PT or 
DF_AD (corresponding to the application classes Point Storage, Ticket, Identification 
Document or Database) can be utilised by the cardholder at the dealer terminal, it 
must be loaded into the VAS-container at a service terminal of the appropriate VAS- 
provider. In principle it is also possible that a card issuer instructed by a VAS- 
provider and an SO loads one or more VAS-applications into the VAS-container 
already when the VAS-container is installed. Such loading process constitutes a 
special case of what is here described. 

Procedure of loading of a VAS-application: 

1 . The cardholder inserts a VAS-card into a service terminal. 

2. The service terminal checks whether a VAS-container is present: 

• SELECT FILE < AID VAS > (error report if VAS-container not selectable) 
READ RECORD < SFI of EFJD, 0 > (display of VAS-container 
number). 

Optionally, the validity of the VAS-container is checked. For this the service 
terminal requires an internal authentication of the VAS-container: 

INTERNAL AUTHENTICATE < random number, KID of K AUT > 

4C 
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The service terminal checks the response and in the event of an error (with 
error display) terminates the procedure. 

The service terminal offers to the cardholder a selection of several options. 
One thereof reads loading VAS-application. This is selected by the 
cardholder. All VAS-applications which can be loaded at the service terminal 
are now displayed to the cardholder and a selection is awaited. For this 
purpose the operation viewing VAS-applications is activated. The cardholder 
selects a VAS-application A of the implementation class DF_PT or DF_AD. 

The service terminal inspects the VAS-container by way of the operation 
selection of a VAS-application, as to whether the selected VAS-application 
having PIX A has already been loaded into the card. In the affirmative, an error 
signal is displayed. If not, a check is made whether an object of the 
implementation class suitable for A is still available in the VAS-container. This 
proceeds by searching for a free record in EF_DIR (e.g. using the command 
SEEK). If nothing is available, an error signal is displayed. If a record is free, 
this contains an FID 0F X of a DF_X into which no VAS-application has been 
loaded. 

The next following free object of the implementation class suitable for A is 
loaded with the VAS-application A. For this purpose the service terminal first 
requests off-line from the VAS-provider (e.g. through a VAS-provider SAM) 
two keys K^m* and K^p and assigns these to the new VAS-application: 

SELECT FILE < FID 0F X > 
GET CHALLENGE 

EXTERNAL AUTHENTICATE < K so (random number), KID of K so > 
UPDA TE KEY < KID of K LVA$P , K LVASP > 
UPDATE KEY < KID of K mASP .K WASP > 
GET CHALLENGE 

EXTERNAL AUTHENTICATE < K,. VAS p (random number), KID of 

KtVASP > 
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UPDATE RECORD < SFI of EFJNFO of DF_X, data > 
UPDATE RECORD < SFI of EFJNTERNAL of DF_X, data > 
Optional (initialling): UPDATE RECORD < SFI of EF_VALUE of 
DF_X, data > 

6. After the successful entry in the EFs the service terminal performs the 
operation enter VAS-appIication < PIX*, FID^ >, which connects the DF_X 
to the PIX A and thereby permits SELECT FILE by means of the PIX A (after the 
- prior selection via SELECT FILE AID VAS ). 

The mechanism made available by way of the transfer storage maiy, for example, be 
utilised by VAS-providers who wish to perform intra- or interservices without 
proprietary DF-structures. A cardholder, in particular prior to using such VAS- 
application, need not then first load this at a service terminal. On the contrary, he 
may issue to himself at the dealer terminal directly a voucher or a receipt and have 
this redeemed at a different terminal (by the operation removing) or simply present 
the voucher or receipt (by reading). Loading of a VAS-application of the 
implementation class EFJTRANSFER is therefore realised implicitly by the entering 
of VAS-data or is caused by such operation. In this context, reference is made to the 
description of the purchase of the implementation class EFJTRANSFER further 
below. 

In the following the course of the operation of entering a VAS-application is 
described. 

If a VAS-application has been loaded into the VAS-container, a terminal will not 
know the physical locality at which DF_X wherein X « PT 1f .... PT pf AD,, .... Ad 8 the 
VAS-application has been loaded or whether it has been loaded at all. From the 
aspect of the card manufacturer two possible implementation modes are possible 
which are to be checked separately; in this context, consistency with the ZKA- 
standard must be particularly observed. 

The first situation: Access to EF_DIR is possible 
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The following preconditions must be met: 

An EF_DIR (e.g. under DF_VAS), in which AIDs are associated with the FIDs 
of the DF_X in which VAS-applications are currently present, exists in 
standard manner in the card platform. 

This EF_DIR is readable by anybody (AC of READ RECORD: ALW). 

If a VAS-application A with PIX A is loaded by the system operator into a free 
(unused) DF_X, i.e. an entry is made into the existing Elementary Files DF_X 
(no CREATE FILE!), it should then be possible to extend the database 
EFJDIR by the entry PIX A by means of an UPDATE RECORD which refers to 
this DF_X by way of FID X . The AC of UPDATE RECORD should therefore 
enforce an external authentication by means of the key Kso. 

If the command SELECT FILE < PIX A > after the prior selection of DF_VAS is 
transmitted to the card, the DF_X into which a VAS-application A has been 
loaded, must be directly selectable. 

If an VAS-application A, loaded into DF_X and its subsidiary Elementary 
Files, is to be deleted at a service terminal at the request of the cardholder, 
the corresponding databases are not deleted by way of DELETE FILE, but 
the entered data are simple written over with dummy values. Thereafter it 
should be possible to delete from EFJDIR the entry PIX A (more specifically 
the pair PIX A and the reference to DFJX) (e.g. by UPDATE RECORD with 
prior external authentication via the key Kso) 

Since the number of DF_X is fixed, the number of records of EF_DIR is 
known. 



If this approach is realisable, the following consequence results: 
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• A direct selection of a VAS-application using SELECT FILE PIX A is possible 
following a selection of DF_VAS. 

The second situation: Access to EF_DIR is not possible 

In the event that with the particular card platform no EF_DIR is available or no 
reading or writing access to this EF_DIR - as described in the previous paragraph - 
is possible, provision is to be made under DF_VAS for a database EF_VASDIR for a 
connection to be made of PIX A loaded VAS-application to their physical storage 
locality in a DF_X, brought about by the system operator by explicit UPDATE 
RECORD commands (after prior external authentication via K so ). Reading and 
deleting of records from EF_VASDIR should be possible as previously described: 

The performance of the operation entry VAS-application proceeds as follows: 

A VAS-application A including PIX A was previously loaded into a free DF_X with 
FID 0F x . The number of the record including FID DF X was noted by the service 
terminal. 

1 . SELECT FILE < AID VAS > (error display if VAS-container not selectable) 

2. GET CHALLENGE 

3. EXTERNAL AUTHENTICATE < K so (random number), KID of K so > 

4. UPDATE RECORD < SFI of EF_DIR of DF_VAS, number record with 
FID 0F x , PIX A> FID DF x > 

VAS-applications of the implementation classes DF_PT or DF_AD can only be 
deleted at the request of the cardholder at the service terminal (being under the 
control of the system operator), VAS-applications of the implementation class 
EF_TRANSFER can be deleted anywhere by anybody. When deleting it is 
necessary to differentiate between VAS-applications of the implementation classes 
DF_PT and DF_AD, respectively the implementation class EFJTRANSFER. 
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Deleting of such VAS-application for the implementation class DF_PT or D_AD 
proceeds as follows: 

1 . The cardholder inserts a VAS-card into a service terminal. 

2. The service terminal checks whether a VAS-container is present: 

SELECT FILE < AID VAS > (error display if VAS-container not 
selectable) 

READ RECORD < EFJD > (display of VAS-container ID) 

3. The service terminal provides the cardholder with a selection of several 
options. One thereof reads delete VAS-application. This is selected by the 
cardholder. All VAS-applications of all implementation classes loaded into the 
VAS-container are now displayed to the cardholder and his selection is 
awaited. For this purpose, the operation viewing VAS-applications is 
activated. The cardholder selects a VAS-application A of the implementation 
class DF_PT or DF_AD by means of AID A . The object into which the VAS- 
application has been loaded is assumed to be denoted DF_A. 

4. After the selection of DF_A, the service terminal authenticates itself: 

SELECT FILE < PIX A > 
GET CHALLENGE 

EXTERNAL AUTHENTICATE < Kgo (random number) , KID of K so > 

5. The content of the files of DF_A is now deleted (K,. VASP is required for 
EF_KEY, EFJNTERNAL and EF_VALUE, for which reason the former is first 
deleted by the system operator): 

UPDATE KEY < KID ofK LVASP) V0...00"> 
UPDATE KEY < KID ol 'K mASF , V0...00"> 
GET CHALLENGE 

EXTERNAL AUTHENTICATE < K LVASP (random number), KID of 

K.VASP > 

UPDATE RECORD < SFI of EFJNFO of DF_A, "00.. .00" > 
UPDATE RECORD < SFI of EFJNTERNAL of DF_A, "00...00" > 
UPDATE RECORD < SFI of EF_VALUE of DF_A, "00.. .00" > 
5. After successful entries into the EFs the service terminal subsequently 
causes the entry of the VAS-application to be deleted from EF DIR: 
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SELECT FILE < AIDv AS > (error display if VAS-container not 
. selectable) 

UPDATE RECORD < SFI of EF_DIR of DF_VAS, number record with 
FID^A, -00...00", FID 0P A > 

The interlinkage of PIX A to DF_A is undone in that SELECT FILE with PIX A is no 
longer possible. 

Next follows the implementation class EF_TRANSFER: 

A VAS-application of the implementation class EF_TRANSFER, in accordance with 
R&R, can only be deleted at the explicit request of a cardholder at a dealer terminal 
or service terminal (even though this might be technically feasible by either). 
Deleting an object from EF_TRANSFER becomes necessary in particular if the 
transfer storage has no more space for storing a new object (e.g. a voucher or a 
receipt). Deleting proceeds always indirectly by way of the supplementary command 
TAKE. This command merely marks an object as having been removed. Thereafter 
it is freed to be overridden by a subsequent supplementary command TRANSFER. 

Deletion of this VAS-application proceeds as follows: 

1 . The cardholder inserts a VAS-card into a terminal capable of displaying the 
content of EF_TRANSFER (special case of viewing operation VAS- 
applications). 

2. The terminal checks whether a VAS-container is present: 

SELECT FILE < AID VAS > (error display if VAS-container not 
selectable) 

READ RECORD < SFI of EFJD, 0 > (display of VAS-container ID) 

3. The terminal makes available to the cardholder a selection of several options. 
One thereof reads delete VAS-application. This is selected by the cardholder. 
At least the VAS-applications of the implementation class EF_TRANSFER 
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are now displayed to the cardholder and a selection is expected. This is 
brought about by a special case of the operation viewing VAS-applications. 
The. cardholder selects an object from the implementation class including a 
voucher or a receipt. This object has the record number A. The cardholder 
activates the selection. 

4. The terminal marks the record with record number A as removed in that it 
transmits A. a random number calculated by it, its PIX and terminal ID, using 
the command TAKE: 

TAKE < A, random number. PIX, terminal ID > 

The record marked as having been removed is now available again for receiving a 
new voucher or a receipt. 

The selection of a VAS-application proceeds as follows: 

In the event that a VAS-application A of the implementation class DF_PT or DF_AD 
has been loaded into the VAS-container by the operation loading VAS-application, 
this can be selected by a terminal in two stages. Firstly, the VAS-container is 
selected and thereafter the VAS-application including its PIX A : 

1 • SELECT FILE < AID VAS > (error display if VAS-container not selectable) 

A service terminal is able to check the authenticity of the VAS-container. For 
that purpose a service terminal demands an internal authentication of the 
VAS-container: 

READ RECORD < SFI of EFJD, 0 > (display of the VAS-container ID) 
INTERNAL AUTHENTICATE < random number, KID of K» 



N AUT 



The service terminal checks the response and interrupts the operation in the 
event of an error (with error display). 
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2. SELECT FILE < PIX A > (error display if VAS-application A has not been 
loaded into the VAS-container) 

A dealer terminal (which has no KGK AUT available) may indirectly determine the 
authenticity of the VAS-container by an authenticity check of the VAS-application A. 
This is so because a VAS-application can only have been loaded at a service 
terminal which during the loading procedure has checked the authenticity of the 
VAS-container. The authenticity check of the VAS-application A can be taken back 
to the test at the dealer terminal whether the VAS-container contains the key K LVASP 
or Krvasp for the VAS-application A. This may be checked by the dealer terminal, e.g. 
as follows: - - - . 

INTERNAL AUTHENTICATE < random number, KID of or K LVAS p > 

In order to test whether a VAS-application A is loaded into the VAS-container, it may 
be selected at random; based on the error display of the response message of 
SELECT FILE, the conclusion may be made that it is not present. 

A selection of a VAS-application of the implementation class EFJTRANSFER results 
implicitly by the operation viewing VAS-applications and the storage of the data in 
the terminal. Since the terminal knows the record number of each indicated object 
from EFJTRANSFER, it is possible to select any desired object for further 
processing with reference to the record number. 

The performance of viewing a VAS-application proceeds as follows: 

The operation viewing of VAS-applications lists at a service terminal all VAS- 
appljcations of the implementation classes DF_PT, DF_AD and EFJTRANSFER. 
Only VAS-applications of the implementation class EFJTRANSFER can be 
displayed at a dealer terminal because of the absence of access protection therefor, 
and optionally also applications of the implementation class DF_PT or DF_AD for 
which the dealer terminal has reader rights (possession of K ftVASP ). 
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Such a VAS-application proceeds as follows: 

1 . The cardholder inserts a VAS-card (chip card with valid VAS-container) into 
the terminal. 

2. The service terminal tests whether a VAS-container is present: 

SELECT FILE < AID VAS > (error display of VAS-container not 
selectable) 

READ RECORD < SFI of EFJD. 0 > (display of VAS-container ID) 

Optionally the validity of the VAS-container is checked. For this purpose the service 
terminal demands an internal authentication of the VAS-container: 

INTERNAL AUTHENTICATE < random number, KID of K AUT > 

The service terminal tests the response and in the event of an error 

(with error display) interrupts the procedure. 

3. The service terminal presents the cardholder with a selection of several 
options. One of these reads viewing VAS-applications. This is selected by the 
cardholder. 

*. The service terminal authenticates itself: 



GET CHALLENGE 

EXTERNAL AUTHENTICATE < K so (random number) , KID of 

Ks 0 > 

For VAS-applications of the implementation classes DF_PT and DF_AD the 
individual VAS-applications are selected, controlled successively by the 
contents of EF_DIR and, after external authentication with the key K so the 
contents of the individual EFJNFO (or part thereof according to R&R) as well 
as EF_VALUE are displayed: 
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• Fori = 0 nr 0lR -1 

• READ RECORD < SFI of EF_DIR, i > 

In the response message PIX A is displayed which is °00..00" if the 
corresponding DF is not loaded with a VAS-application. As an 
alternative to READ RECORD from EF_DIR it may also be 
possible to employ a SEEK command. 

• If PIX A does not equal "00..00" 

• SELECT FILE < PIX A > 

• READ RECORD < SFI of EFJNFO, 0 > 

• Display (optionally only in part) of the response message 

• READ RECORD < SFI of EF_VALUE, 0 > 

• SELECT FILE < AID VAS > 

6. For VAS-applications f the implementation class EF_TRANSFER the contents 
(or a portion thereof according to R&R) of the EF_TRANSFER of each record 
is displayed: 

SELECT FILE <AID VAS > 

* If i = 0 nr ef transfer • 1 

• READ RECORD < SFI of EFJTRANSFER. i > 

(the response message displays the contents of the i-th records of 
EFJTRANSFER) 

If the contents are not empty, the contents is displayed in 
interpreted form (e.g. taken out/expired). 



Viewing of the applications of the implementation class DF_PT or DF_AD for which 
the dealer terminal has viewing rights (possession of K SVASP ), proceeds as described 
- subject to two changes: For external authentication the key K RVASP is used instead 
of Kso which is available only to the system operator. If a dealer terminal does not 
have available KGK AUT and nevertheless wishes to check the authenticity of the 
VAS-applications, the dealer terminal instead of internal authentication may demand 
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the authentication (of at least one) VAS-application. This proceeds as described by 
the knowledge of the card of the corresponding K^^p or K^p key. 

For VAS-applications of the implementation class EFJTRANSFER the contents (or a 
portion thereof according to R&R) of EFJTRANSFER of each record are listed 
successively as previously described. 

The operation interpretation VAS-applications proceed analogous thereto. For that 
purpose the terminal offers the cardholder an option interpretation VAS-applications 
for selection. In addition to the data which become displayed due to the operation 
viewing, it is possible to also display data from EFJNFO and EFJ/ALUE which 
require an interpretation by the VAS-provider (e.g. externally encoded data) and 
data from EFJNTERNAL (e.g. miles from previous years with Miles & More). This, 
however, is possible only for the VAS-applications for which a VAS-provider (at his 
own option) makes available at the terminal suitable keys. The key K LVASP (external 
authentication) is required for reading the EFJNTERNAL of a VAS-application. For 
externally encoded data within the Elementary Files EFJNFO, EFJNTERN and 
EF_VALUE as well as the transfer storage EFJTRANSFER the appropriate keys of 
the VAS-provider are required. The terminal programme can readily distinguish with 
the aid of the PIX of a selected VAS-application, for which applications keys are 
available for the interpretation of the data. 

The operation transfer of VAS-applications denotes the transfer of all or selected 
VAS-operations of a source card onto a target card at a service terminal. This is 
subject to the precondition that in the VAS-container of the target card, no VAS- 
applications are loaded and that after the transfer all VAS-applications are deleted 
from the source card. Both may be attained by successive applications of the 
operation delete a VAS-application. Furthermore the authenticity of the VAS-card 
must be checked and the target card must provide adequate storage capacity. The 
operation transfer itself is based essentially on an extension of the operation viewing 
of VAS-applications for which additionally the data from EFJNTERNAL and the 
keys Kt.vASp and K qvASP are read and on a repeated application of the operation 
loading a VAS-application. 
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Jointly with the VAS-data the VAS-container ID as well is transferred to the target 
card in order for the VAS-applications of the target card to perform exactly as they 
did on the source card. The reasons therefor is that keys derived from a VAS- 
provider are supported by the VAS-container ID, the keys, however, being copied 
without change. Moreover, a VAS-provider does not wish to change his accounting 
in the basic system because he normally identifies VAS-cards by way of the VAS- 
container ID. It is essential to ensure that during the transfer of the VAS-container ID 
this number which is unique for the system, is deleted from the source card. 

In order to be able to specifically read the Elementary File EFJNTERNAL and the 
keys Klvasp and K^p; the service terminal, after an external authentication by 
means of the key Kso (as in the operation deleting a VAS-apptication) first overwrites 
the key and then after a renewed authentication with K LVASP overwrites the 

data from EFJNTERNAL. 

In addition to the VAS-applications of the implementation classes DF_PT and 
DF_AD, the file EF_TRANSFER must be overwritten. For this purpose the operation 
remove is used successively to remove the objects of this implementation class 
which have not yet been marked as removed or expired, checks their signature by 
way of Ksiq VASC and performs the transfer into the EFJTRANSFER of the target 
card. On the target card, on the other hand, the objects are denoted as not 
removed, so that they will remain valid. 

Finally, the global data of the VAS-container must be transferred. In particular, the 
sequence number of the target card must be adjusted to the value of the source 
card. 

The procedure of entering VAS-data is described in what follows: 

There are three possible cases of entering VAS-data at a dealer terminal which 
depend on the nature of the VAS-application. 
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Firstly, the purchase in the event of implementation class DF_PT or OF AD 

A VAS-provider is to enter data into a VAS-application A of the implementation class 
DF_PT or DF_AD. 

The entering of the VAS-data proceeds as follows: 

1 • The cardholder inserts a VAS-card into a dealer terminal. 

2. The dealer terminal checks whether a VAS-container is present: 

SELECT FILE < AID^ > (error display if VAS-container not 
selectable) 

READ RECORD < SFI of EFJD, 0 > (display of VAS-container ID) 

3, The authenticity of the VAS-container is checked. 

If the dealer terminal itself is in possession of the master key KGK AUT , it can 
demand an internal authentication of the VAS-container: 

• INTERNAL AUTHENTICATE < random number, KID of K AUT > 

A dealer terminal (which does not have available the KGK AUT ) may indirectly 
check the authenticity of the VAS-container by the authenticity check of the 
VAS-application A. The reasons is that a VAS-application can only have been 
loaded at a service terminal which during loading had checked the 
authenticity of the VAS-container. The authenticity check of the VAS- 
application A can be referred back to the test of the dealer terminal whether 
the VAS-container contains the key K LVASP or the key K RVASP for the VAS- 
application A. This may be checked by the dealer terminal, e.g. by: 

SELECT FILE < PIX A > (error display if VAS-application A not loaded 
into the VAS-container) 

INTERNAL AUTHENTICATE < random number, KID of K RVASP or 

Klvasp > 
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The dealer terminal checks the response and in the event of error (with error 
display) breaks off the procedure. 

4. The dealer terminal selects the VAS-application A, authenticates itself and 
describes the Elementary Files which are necessary for performing the 
transaction: 

• SELECT FILE < PIX A > (obviated if already performed in step 3) 
GET CHALLENGE 

• EXTERNAL AUTHENTICATE < K^y^p (random number), KID . 

optional: UPDATE RECORD < SFI of EFJNFO of DF_X. data > 
optional: UPDATE RECORD < SFI of EFJNTERNAL of DF_X, data > 
optional: UPDATE RECORD < SFI of EF_VALUE of DF_X, data > 

Now follows the purchase in the case of implementation class EFJTRANSFER 

Specifically for VAS-applications of the implementation class EFJTRANSFER 
(application class Voucher) a VAS-provider need not occupy a proprietary file 
structure DF_X for his application. The result is that a cardholder need not, prior to 
using a VAS-application voucher, go to a service terminal in order to load a VAS- 
application. He may rather, directly at the dealer terminal, issue a voucher or a 
receipt and have these reimbursed at a different terminal (by the operation 
removing) or simply show the voucher or receipt (by reading). The entering of VAS- 
data accordingly results in an implicit loading of VAS-applications of the 
implementation class EFJTRANSFER. For this application class the implementation 
class EFJTRANSFER exists which is composed of individual objects of the type 
record. An entry in EFJTRANSFER is possible exclusively by the command 
TRANSFER. The dealer terminal must for that purpose be in possession of a valid 
cancellation key and must have available a PIX A of the VAS-application A. 

The entering of VAS-data proceeds as follows: 
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1 . The cardholder inserts a VAS-card into a dealer terminal. 

2. The dealer terminal checks whether a VAS-container is present: 

SELECT FILE < AID VAS > (error display if VAS-container not 
selectable) 

READ RECORD < SFI of EF-ID, 0 > (display of VAS-container 
number) 

3. The dealer terminal reads the sequence number which additionally enters the 
MAC from step 4: 

READ RECORD < SFI of EF_SEQ, 0 > (display of sequence number) 

4. The command TRANSFER causes a record to be entered in EFJTRANSFER: 

TRANSFER < transaction date, expiry date, generator code, data, 
PIX A , MAC with Ko 6C > 

5. The dealer terminal can check by inspection of the response message of the 
TRANSFER command whether the VAS-container is genuine (i.e. in 
possession of the joint secret K^). In this context reference is also made to 
the response message following the command TRANSFER, described further 
above. 

Finally, the purchase of VAS-data by value cancellation 

A VAS-provider may by a value cancellation step using the command TRANSFER in 
the transfer field EFJTRANSFER generate an entitlement (e.g. voucher or receipt) 
which can be further used by a different VAS-provider. Data are cancelled from the 
EFJ/ALUE or EFJNFO of the VAS-application A of the VAS-provider effecting the 
cancellation. The cardholder acquires the right in the form of an object in 
EFJTRANSFER. 

The entry of VAS-data proceeds as follows: 
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The cardholder inserts a VAS-card into a dealer terminal. 

The dealer terminal checks whether a VAS-container is present: 

SELECT FILE < AID VAS > (error display if VAS-container not 
selectable) 

READ RECORD < SFI of EFJD, 0 > (display of VAS-container ID) 

The dealer terminal reads the sequence number which, in addition, enters the 
MAC in the course of step 4: : - 

READ RECORD < SFI of EF_SEQ, 0 > (display of sequence number) 

The dealer terminal selects the VAS-application A: 

SELECT FILE < PIX A > (error display, if VAS-application A has not 
been loaded into the VAS-container) 

The dealer terminal uses the command TRANSFER for cancelling the data 
from the EF_VALUE or the EFJNFO as the case may be. 

TRANSFER < data, MAC with Ko EC > 

The composition of the command message of TRANSFER has already 
been described. The entitlement to perform the cancellation is 
obtained by the terminal rf it can form a correct signature concerning 
the data by means of the Ko ec . This signature is checked by the VAS- 
container. If successful, a record is set up in EFJTRANSFER by the 
VAS-container and the sequence number is incremented. 

The dealer terminal can check by checking the response message of the 
TRANSFER command whether the VAS-container is authentic (i.e. in 
possession of the common secret K oec ). 
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We shall now deal with the procedure for cancelling VAS-data. There are two kinds 
of cancellation procedures: 

On the one hand, VAS-data for VAS-applications of the implementation class 
DF _ PT or DF_AD may be cancelled by the appropriate VAS-provider by the 
operation cancellation, i.e. purchase of VAS-data by cancellation. In that manner, a 
value is consumed, whereby a potential entitlement to a different value is created. 

On the other hand, VAS-data may be withdrawn from the EFJTRANSFER once only 
by the supplementary command TAKE. In that instance, the entitlement is 
consumed, the data remain for possible further use (e.g. refunded ticket is still 
required for the return trip) in the transfer field, denoted as having been removed 
until overridden by other objects, when required. 

Cancellation of VAS-data by the command TAKE proceeds as follows: 

1 . The cardholder inserts a VAS-card into a dealer terminal. 

2. The dealer terminal checks whether a VAS-container is available: 

SELECT FILE < AID VAS > (error display if VAS-container not 
selectable) 

READ RECORD < SF1 of EFJD, 0 > (display of VAS-container ID) 

3. The dealer terminal first displays from EFJTRANSFER the objects which are 
available using the special case of operation viewing VAS-applications in 
order to decide whether a required object is available. Alternatively, the 
command SEEK may be employed for seeking a sample. The terminal, if 
successful, knows the number i of the record searched for. 

4. The terminal marks the record to show record number i in that it transmits i f a 
random number calculated by it, its PIX and terminal ID with the command 
TAKE: 
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TAKE < i, random number, PIX, terminal ID > 

The dealer terminal uses the command TAKE for reading the data from the 
EF_TRANSFER, simultaneously identifying the data as having been taken out. The 
execution of the command, in addition, brings about the generation of two different 
cryptograms C, and C 2 . 

The cryptogram C, is calculated by the VAS-container using the key K SIG VASC . In this 
manner the producer of the removed object signed with C, can obtain evidence of 
uniqueness and authenticity from the system operator. The uniqueness ■ and 
authenticity of the transaction arises from the cryptogram of the VAS-provider from 
which the object initially originated (and which was checked by the card, see also 
TRANSFER), and from the maintenance of a sequence counter over the 
transactions as well as the cryptogram C, by the card during the withdrawal. 

The cryptogram C 2 is calculated by the VAS-container using the key KGK 0EC , which 
is derived by the VAS-container from KGKoec, PIX and terminal ID. By having 
knowledge of the joint secret Ko EC , the VAS-container can directly verify to the 
terminal the authenticity of the VAS-container. Due to the fact that during the 
TRANSFER command a check is likewise made that only genuine vouchers or 
receipts are stored in an authentic VAS-container, the authenticity of the withdrawn 
object can be concluded. Since C 2 is formed indirectly via the sequence number, 
the withdrawal bit and the VAS-container ID, the VAS-container can even verify to 
the terminal the uniqueness of the object withdrawn. 

Anybody has the right to withdraw using the command TAKE. 

Moreover, at the service terminal the deactivation or activation respectively of a 
password or a PIN-protection for the reading of VAS-applications of the 
implementation classes DF_PT and DF_AD is possible. In addition, the PIN of the 
VAS-container can be altered by the cardholder having knowledge of the PIN and 
may be restored by the system operator by means of external authentication by K so . 
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Non-riumerical symbols or symbol sequences of optional length can also be used as 
PIN or password. 
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Patent Claims ^ 

1 . Chip card for performing transactions in which monetary units or other 
value data representing non-monetary entitlements are transferred between the 
cardholder and at least one transaction partner (service provider) or are presented 
to the sen/ice provider for verification of entitlements, wherein the chip card 
includes a storage, in which data required for performing the transactions are stored 
and the chip card is characterised in that it comprises the following: 

a means for loading one or more card applications (VAS-applications) which 
are assigned to a certain service provider, respectively,, onto the card which each 
permits the performance of transactions between the cardholder the service 
provider assigned to the application; 

a transfer memory portion (EFJTRANSFER) which is not proprietory to a 
service provider for accomodating data which in the performance of a transaction 
between different service providers are to be interchanged or presented and which 
represent the monetary units or non-monetary entitlements; and 

a means for writing data into the transfer storage by reaction to a write 
command (Transfer). 

2. Chip card according to claim 1, in which the means for loading 
comprise: 

a data structure (DF_VAS, VAS-container) stored therein which includes: 
a partial structure (DF_PT, DF_AD, VAS -application) into which the data 

required (VAS-data) for making possible the performance of a transaction between 

the cardholder and a service provider can be loaded; 

a definition data set which contains information concerning the nature and/or 
structure of the data stored in the partial structure (VAS-application); and wherein 
the definition data set further comprises: 

a denotation (container-ID) which identifies the data structure (VAS- 
container) and/or the chip card; and 
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at least one system key (Kso) which secures the integrity of the definition 
data set and/or the data structure (VAS-container) against modifications. 

3. Chip card according to claim 1 or 2, characterised in that it comprises 
at least one of the following features: 

a means for loading data necessary for the performance of transactions into 
the partial structure with the aid of at least one system key; 

a means for the writing of data into the definition data set for adapting the 
data of the definition data set to the data loaded into the partial structure; 

a means for generating a further partial structure into which data required for 
performing a transaction can be loaded in the database of the card; and/or 

a means for dynamic memory administration on the card. 

4. Chip card according to any one of the preceding claims, characterised 

in that 

the partial structures (VAS-applications) are represented by mutually 
independent partial structures each being assigned to a particular service provider, 

the definition data set is protected against modification by the at least one 
system key (Kso) and can only be modified by means of this key, and that 

loading of the partial structures (VAS-applications) can proceed only with the 
use of the system key contained in the definition data set. 

5. Chip card according to any one of the preceding claims, characterised 
in that the definition data set comprises at least one of the following features: 

at least one authentication key (K AUT ) for authenticating the entitlement of the 
chip card in relation to a terminal and/or for authentication of the entitlement of a 
terminal in relation to the chip card; 

at least one signature key (Ksiq_vasc) for signing data removed from the 
transfer storage; 
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a key generating key (KGKqec) for generating terminal and application- 
specific keys for the verification of the authorisation for a writing procedure into the 
transfer storage and/or a invalidation of value data; 

a PIN for the verification of the authorisation of a transaction procedure by 
the cardholder, ■ 

that the system key (Kso). the authentication key (Kaut), the signature key 
(Ksig_vasc) and the key generating key (KGKqec) are keys individual to the cards or 
specific to the data structure (DF_VAS), 

and that the partial structure (VAS-application) comprises at least one of the 
following features: 

at least one value storage (EF_VALUE) for the storage of value data; 

at least one internal storage (EFJNTERNAL) for the storage of internal data 
relating to the partial structure; 

at least one information storage (EFJNFO) for the accommodation of non- 
internal data relating to the partial structure; 

a key storage (EF_KEY) for accommodating at least one key (Klvasp. 
Krvasp), which provides security for the writing and/or information retrieval 
procedure into or from the value storage and/or the internal storage and/or the 
information storage and that the chip card further includes: 

a means for writing and/or retrieving data into or from the value storage, the 
internal storage or the information storage and that the means for loading includes: 

a means for writing the key into the key storage, protected by the at least 
one system key. 

6. Chip card according to any one of the preceding claims, characterised 
in that the partial structure comprises at least one of the following integers: 

a key (K LVA sp) for checking the authorisation to write data in the partial 
structure: 

a key (Krvasp) for checking the authorisation to retrieve data from the partial 
structure. 
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7. Chip card according to any one of the preceding claims, characterised 
in that keys stored in the key storage are specific for the respective partial structure 
and that the 

at least one partial structure (VAS-application) protects the performance of 
transactions by means of at least one of the specific keys (Klvasp. Krvasp) which is 
specific to the respective partial structure (VAS-application) and is independent of 
the keys for other partial structures (VAS-applications). 

8. Chip card according to any one of the preceding claims, characterised 
in that the card comprises a plurality of partial structures (VAS-applications) which 
each serve for the performance of transactions between a particular service 
provider and the cardholder and that 

the performance of transactions includes the writing and/or retrieval of data 
into, respectively from the transfer field and/or the writing and/or retrieval of data 
into, respectively out of the value storage. 

9. Chip card according to any one of the preceding claims, characterised 
in that it further includes: 

a means for performing transactions both between individual partial 
structures (VAS-applications) as well as between a partial structure and a service 
provider. 

1 0. Chip card according to any one of the preceding claims, characterised 

in that 

the system key (K so ) is known only to the system operator (SO) and is a key 
individual to a card and/or specific to a data structure (VAS-container), and that 

the further keys contained in the definition data set are keys individual to the 
card and/or specific to the data structure (VAS-container). 

1 1 . Chip card according to any one of the preceding claims, characterised 
in that the definition data set includes one or more of the following integers: 

an identification number (EFJD) specifying the data structure 
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a directory of partial structures (EFJDIR) contained in the data structure, the 
directory containing partial structure specific identification numbers of partial 
structures (VAS-applications) loaded into the data structure (VAS-container), as 
well as information containing that part of the data structure (VAS-container) in 
which the partial structures (VAS-applications) are physically stored; 

a version number of the data structure (EF_VERSION) . 

12. Chip chard according to any one of the preceding claims, 
characterised in that it includes at least one of the following features: 

a means for performing a withdrawal procedure (Take) by means of which 
data can be removed and/or value-cancelled from the transfer storage; 

a means for generating one or more authenticity features of the data during 
withdrawal or cancellation of data from the transfer storage. 

13. Chip card according to any one of the preceding claims, characterised 
in that the chip card for generating the authenticity features comprises the following: 

a signature key (Ksigj/asq for generating a digital signature having the data 
withdrawn; 

a means for generating a transaction number characterising the transaction 
which is also used in the generation of the digital signature. 

14. Chip card according to any one of the preceding claims, characterised 
in that the signature key (K S ig_vasq is a private key, derived from a private key 
generating key and that for checking the signature by the service provider, public 
keys are employed. 

15. Chip card according to any one of the preceding claims, characterised in 
that it at least comprises one of the following integers: 

a means for generating terminal and partial structure-specific keys (Kqec) by 
means of the key generating key (KGKoec); 

a means for verifying the authorisation and/or the protection of a transaction 
by using at least one of the following integers: 
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the terminal and partial structure-specific key (K D ec), 
the at least one authentication key (Kaut), 
the at least one system key (Kso). 

the at least one partial structure specific key (K LVA sp. Khvasp), 
the signature key (Ksi G _vasc). 
the PIN, 

the identification of a partial structure, 
the identification of a terminal. 



1 6. Chip card according to any one of the preceding claims, characterised 
in that the chip card includes at least one of the following integers: 

a means for authentication of the authority and/or the terminal by means of 
the authentication key prior to starting a data retrieval or writing procedure, 

a means for performing data retrieval or writing procedures which are 
protected by a digital signature and/or key formation. 

17. Chip card according to any one of the preceding claims, characterised 
in that the chip card further includes at least one of the following, integers: 

a means for activating and deactivating the PIN-protection, 
a means for changing the PIN. 

1 8. Chip card according to any one of the preceding claims, characterised 
in that the data structure according to any one of the preceding claims is 
independent of the card platform and the chip card further includes: 

a means for transferring the data structure or of parts of the data structure to 
another card. 

19. Chip card characterised in that it comprises the following: 

a storage region not proprietory to a service provider for the writing or 
retrieval of data into or out of the storage region by different service providers for 
the transfer of monetary units and/or of value data representing other non-monetary 
entitlements between different service providers. 
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20. Terminal for the use of a chip card according to any one of claims 1 to 
19, characterised in that the terminal comprises: 

a means for identifying the data structure (VAS-container) of the chip card as 
well as for identifying the characterisation (container- ID) identifying the data 
structure; 

and that it further comprises at least one of the following features: 

a means for retrieval of data from at least one of the partial structures and/or 
the definition data set and/or the transfer storage of the card; 

a means for writing of data into the transfer storage of the card; 

a means for loading the data required for the performance of transactions 
into at least one of the partial structures (VAS-applications) of the card. 

21. Terminal according to claim 20, characterised in that it comprises at 
least one of the following integers: 

a means for performing transactions between a service provider and the 
cardholder wherein the performance of a transaction includes at least one of the 
following steps: 

the writing of data into the value storage, 

the writing of data into the transfer storage, 

the removal and/or cancellation of data from the transfer storage, 

the retrieval of data from the partial structure, 

the retrieval of data from the transfer storage. 

22. Terminal according to either of claims 20 or 21 , characterised in that it 
further comprises: 

a means for verifying the authorisation for and/or the protection of a 
transaction with the aid of at least one of the following integers: 
a terminal and partial structure-specific key (K DE c), 

the at least one authentication key (Kaut) which is individual to the card or 
specific to the data structure (DF_VAS), 



CA 0227S93J 1999-06-22 



-8- 

at least one system key (K so ) which is individual to the card or specific to the 

data structure (DF_VAS), 

at least one partial structure specific key (K LV asp, Krvasp), 

at least one signature key (Ksig.vasc) which is individual to the card or 

specific to the data structure (DF_VAS) , 

a PIN which is individual to the card or specific to the data structure 
(DFVAS), 

an application-specific characterisation of a partial structure, 
a terminal-specific characterisation of a terminal. 

23. Terminal according to any one of claims 20 to 22, characterised in 
that the means for writing data into the transfer storage comprises: 

a means for encoding of data with the use of a terminal and partial structure 
specific key (K DE c) for verification of the write authorisation. 

24. Terminal according to any one of claims 20 to 23, characterised in 
that it further comprises: 

a means for performing a process of withdrawing data from the transfer 
storage by means of which data are removed from the transfer storage and/or are 
value cancelled. 

25. Terminal according to any one of claims 20 to 24, characterised in 
that it further comprises at least one of the following integers: 

a means for characterising data of the transfer storage as having been 
removed, 

a means for characterising data of the transfer storage as having expired. 

26. Terminal according to any one of claims 20 to 25, characterised in 
that the means for performing transactions comprises at least one of the following 
integers: 

a means for changing value data in the partial structure; 
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a means for performing transactions between different service providers 
(interservices) at the expense of, respectively for the benefit of the cardholder. 

27. Terminal according to any one of claims 20 to 26, characterised in 
that it further comprises: 

a means for the authentication of the authority of the terminal in relation to 
the card and/or the card in relation to the terminal with the aid of at least one 
authentication key; 

a means for protecting a transaction by the cardholder by means of a PIN; 

a means for activating and deactivating the PIN-protection. 

28. Terminal according to any one of claims 20 to 27, characterised in 
that it further comprises at least one of the following integers: 

a means for transferring a terminal specific characterisation to the card; 
a means for transferring a characterisation specifying the partial structure to 
the card; 

a means for authentication of the authorisation using a terminal and partial 
structure specific key as well as the terminal and partial structure specific 
characterisation, 

a means for performing data retrieval or writing procedures which are 
protected by a digital signature and/or encodification. 

29. Terminal according to any one of claims 20 to 28, characterised in 
that it further comprises at least one of the following integers: 

a means for selecting a partial structure (VAS-application); 
a means for viewing a partial structure at the terminal; 
a means for viewing the data of a partial structure at the terminal; 
a means for loading a partial structure (VAS-application) onto the card; 
a means for loading a characterisation onto a loaded partial structure (VAS- 
application) onto the card, 

a means for deleting a partial structure from the card, 

a means for substituting a partial structure by a different partial structure; 
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a means for transferring a partial structure onto another card; 

a means for interpreting a partial structure with regard to its function and its 
associate service provider as well as for data retrieval and viewing of information 
stored therein. 

30. Process for performing transactions between a cardholder and at 
least one service provider involving the use of a chip card as well as a terminal 
wherein the process comprises one of the following steps: 

Provision of a data structure stored on the chip card into which data of a card 
application proprieotory to a service provider can be loaded for enabling the 
performance of the transaction between the cardholder and said service provider 
(VAS-data); as well as 

writing into or reading of data from the data structure (VAS-application) for 
performing transactions between the cardholder and said service provider; 

provision of a transfer storage region (EF_TRANSFER) not proprietory to a 
service provider for the storage of monetary units or data representing non- 
monetary entitlements to be exchanged or presented during the performance of the 
transaction between different service providers, as well as 

writing of data into the transfer storage or retrieval of data from the transfer 
storage. 

31. Process according to claim 30, characterised in that the process 
comprises at least one of the following steps: 

Use of a chip card according to any one of claims 1 to 19 ; 
use of a terminal according to any one of claims 20 to 30; 
writing or retrieval of data into or from the value storage or internal storage or 
information storage of at least one of the partial structures (VAS-applications). 

32. Process according to claim 30 or 31, characterised in that it 
furthermore includes at least one of the following steps: 

authentication of the authority of the terminal and/or the chip card with the 
use of at least one key; 
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protection of the transaction by the use of a digital signature and/or 
encodification by the use of at least one key. 

33. Process for loading of data onto a chip card using a terminal, 
characterised in that the process comprises at least one of the following steps: 

Loading of data into a partial structure (VAS-application) of the card; 

writing of data into the definition data set of the card, said process 
comprising at least one other following steps: use of a chipcard according to one of 
claims 1 to 19; 

use of a terminal according to one of claims 20 to 29. 

34. System for performing transactions, characterised by a chip card 
according to any one of claims 1 to 19 and a terminal according to any one of 
claims 20 to 29. 
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